ReactivePullStrategy
Related Docs:
class ReactivePullStrategy
| package rstreams
This strategy pre-allocates a buffer of the given size and waits for it to fill up before emitting it downstream.
This strategy pre-allocates a buffer of the given size and waits for it to fill up before emitting it downstream.
Additional events are requested only after the buffer is emitted.
This strategy is more efficient than StopAndWait, but
less fair. For example if you have a producer that emits
a tick every second, with a bufferSize of 10 the consumer
will only see events every 10 seconds. Therefore it should
be used with a busy source, but for slow producers
StopAndWait is a better strategy.
This strategy consumes the elements from a Publisher
one by one, with acknowledgement required for each event.
This strategy consumes the elements from a Publisher
one by one, with acknowledgement required for each event.
In this mode the consumer must indicate its readiness to
receive data after every event and the consumer must wait
on that acknowledgement. Technically what this means is that for
each element the consumer needs to do a request(1) call.
This could be the same as FixedWindow(1) (see FixedWindow),
however internally implementations can optimize for stop-and-wait
flow control. For example a buffer is not necessarily required.
Pros and Cons of stop-and-wait strategy:
Default buffering strategy used when not overridden by a user-defined implicit.