Interface describing Observer wrappers
that are thread-safe (can receive concurrent events) and that
return an immediate Continue
when receiving onNext
events.
Wraps an underlying
Subscriber into an implementation that caches
all events until the call to connect()
happens.
Wraps an underlying
Subscriber into an implementation that caches
all events until the call to connect()
happens. After being connected,
the buffer is drained into the underlying
observer, after which all
subsequent events are pushed directly.
Wraps a Subscriber into an implementation that abstains from emitting items until the call
to connect()
happens.
Wraps a Subscriber into an implementation that abstains from emitting items until the call
to connect()
happens. Prior to connect()
it's also a Channel into which you can enqueue
events for delivery once connect()
happens, but before any items
emitted by onNext
/ onComplete
and onError
.
Example:
val obs = ConnectableObserver(observer) // schedule onNext event, after connect() obs.onNext("c") // schedule event "a" to be emitted first obs.pushNext("a") // schedule event "b" to be emitted second obs.pushNext("b") // underlying observer now gets events "a", "b", "c" in order obs.connect()
Example of an observer ended in error:
val obs = ConnectableObserver(observer) // schedule onNext event, after connect() obs.onNext("c") obs.pushNext("a") // event "a" to be emitted first obs.pushNext("b") // event "b" to be emitted first // schedule an onError sent downstream, once connect() // happens, but after "a" and "b" obs.pushError(new RuntimeException()) // underlying observer receives ... // onNext("a") -> onNext("b") -> onError(RuntimeException) obs.connect() // NOTE: that onNext("c") never happens
A safe observer ensures too things:
A safe observer ensures too things:
- errors triggered by downstream observers are caught and streamed to onError
,
while the upstream gets an Ack.Cancel
, to stop sending events
- once an onError
or onComplete
was emitted, the observer no longer accepts
onNext
events, ensuring that the Rx grammar is respected.
- if downstream signals a Cancel
, the observer no longer accepts any events,
ensuring that the Rx grammar is respected.
This implementation doesn't address multi-threading concerns in any way.
A SynchronousObserver
is an Observer that signals demand
to upstream synchronously (i.e.
A SynchronousObserver
is an Observer that signals demand
to upstream synchronously (i.e. the upstream observable doesn't need to
wait on a Future
in order to decide whether to send the next event
or not).
Can be used for optimizations.
A SynchronousSubscriber
is a Subscriber whose onNext
signal
is synchronous (i.e.
A SynchronousSubscriber
is a Subscriber whose onNext
signal
is synchronous (i.e. the upstream observable doesn't need to
wait on a Future
in order to decide whether to send the next event
or not).
Interface describing Observer wrappers that are thread-safe (can receive concurrent events) and that return an immediate
Continue
when receivingonNext
events. Meant to be used by data sources that cannot uphold the no-concurrent events and the back-pressure related requirements (i.e. data-sources that cannot wait onFuture[Continue]
for sending the next event).Implementations of this interface have the following contract:
onNext
/onError
/onComplete
of this interface MAY be called concurrentlyonNext
SHOULD return an immediateContinue
, as long as the buffer is not full and the underlying observer hasn't signaledCancel
(N.B. due to the asynchronous nature,Cancel
signaled by the underlying observer may be noticed later, so implementations of this interface make no guarantee about queued events - which could be generated, queued and dropped on the floor later)onNext
MUST return an immediateCancel
result, after it notices that the underlying observer signaledCancel
(due to the asynchronous nature of observers, this may happen later and queued events might get dropped on the floor)Cancel
), or when a concurrent upstream data source triggered an error, this SHOULD eventually be noticed and acted uponCancel
, then implementations of this interface SHOULD not lose events in the processonError
triggered in the underlying observer coupled with aCancel
signaled to the upstream data sources, or dropping events from the head or the tail of the queue, or attempting to apply back-pressure, etc...See OverflowStrategy for the buffer policies available.