Related to https://github.com/apache/pulsar-client-reactive/pull/28/files#r1033276692
The way the backpressure solution works is that InflightLimiter will never create more demand with ReactiveStreams subscription requests than the configured limit.
This is a bit hard to understand in practice because of the way how ReactiveStreams model works. It's a pull-push model where the "pull" is created with subscription requests. The backpressure is handled by limiting the amount of upstream requests. Subscribing to upstream publishers that are creating messages to send will also be postponed when limits are exceeded.
Adding unit tests and documentation to the underlying InflightLimiter would clarify the details and ensure that there aren't uncovered gaps in the solution.
Related to https://github.com/apache/pulsar-client-reactive/pull/28/files#r1033276692
The way the backpressure solution works is that InflightLimiter will never create more demand with ReactiveStreams subscription requests than the configured limit.
This is a bit hard to understand in practice because of the way how ReactiveStreams model works. It's a pull-push model where the "pull" is created with subscription requests. The backpressure is handled by limiting the amount of upstream requests. Subscribing to upstream publishers that are creating messages to send will also be postponed when limits are exceeded.
Adding unit tests and documentation to the underlying InflightLimiter would clarify the details and ensure that there aren't uncovered gaps in the solution.