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()
you can enqueue
events for delivery once connect()
happens, but before any items
emitted by onNext
/ onComplete
and onError
.
Example:
val out = ConnectableSubscriber(subscriber) // schedule onNext event, after connect() out.onNext("c") // schedule event "a" to be emitted first out.pushFirst("a") // schedule event "b" to be emitted second out.pushFirst("b") // underlying observer now gets events "a", "b", "c" in order out.connect()
Example of an observer ended in error:
val out = ConnectableSubscriber(subscriber) // schedule onNext event, after connect() out.onNext("c") out.pushFirst("a") // event "a" to be emitted first out.pushFirst("b") // event "b" to be emitted second // schedule an onError sent downstream, once connect() // happens, but after "a" and "b" out.pushError(new RuntimeException()) // underlying observer receives ... // onNext("a") -> onNext("b") -> onError(RuntimeException) out.connect() // NOTE: that onNext("c") never happens
A safe subscriber safe guards subscriber implementations, such that:
A safe subscriber safe guards subscriber implementations, such that:
onComplete
and onError
signals are back-pressuredAck.Stop
, to stop sending eventsonError
or onComplete
was emitted, the observer no longer accepts
onNext
events, ensuring that the grammar is respectedStop
, the observer no longer accepts any events,
ensuring that the grammar is respected
A Subscriber
is a named tuple of an observer and a scheduler.
A Subscriber
is a named tuple of an observer and a scheduler.
A Subscriber
value is an address that the data source needs
in order to send events.
A SyncObserver
is an Observer that signals demand
to upstream synchronously (i.e.
A SyncObserver
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 SyncSubscriber
is a Subscriber whose onNext
signal
is synchronous (i.e.
A SyncSubscriber
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 signaledStop
(N.B. due to the asynchronous nature,Stop
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 immediateStop
result, after it notices that the underlying observer signaledStop
(due to the asynchronous nature of observers, this may happen later and queued events might get dropped on the floor)Stop
), or when a concurrent upstream data source triggered an error, this SHOULD eventually be noticed and acted uponStop
, then implementations of this interface SHOULD not lose events in the processonError
triggered in the underlying observer coupled with aStop
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.