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
Continuewhen receivingonNextevents. 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/onCompleteof this interface MAY be called concurrentlyonNextSHOULD 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,Cancelsignaled 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)onNextMUST return an immediateCancelresult, 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 processonErrortriggered in the underlying observer coupled with aCancelsignaled 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.