1.x: fix counted buffer and window operators' backpressure behavior #3597
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes the backpressure behavior of the counted
bufferandwindowoperators and consists of several changes.The main issue lies when
count > skipin the operators, yielding overlapping buffers/windows.For
buffer, when the upstream completed, the logic emitted all remaining partial buffers even if there was no request for new buffers, which can result inMissingBackpressureExceptionsomewhere. The proper handling of the final buffers required a new backpressure management algorithm which is now part of theBackpressureUtilsclass and consists of two new methods:postCompleteDonecalled from onComplete to take over the emission of queued values andpostCompleteRequestwhich manages requests before and after the completed state.For
window, the new window opened was emitted regardless of requests which was common due to request-amplification (i.e., requesting n windows results in requestingcount + skip * (n - 1)elements at first (thenskip * nlater) which opensceil(count / skip)windows upfront. To avoid the overflow, the individual windows have to go through the usual queue/drain logic as well. I've also updated the Javadoc to reflect the backpressure behavior along with parameter validation.In addition, the window case didn't manage cancellation properly. When the outer observable is unsubscribed, the inner subscribers may be still going and thus cancelling the upstream would stop/hang the inner windows. Instead, the open window count is tracked (also counting the outer as 1 window) and when all get unsubscribed (i.e., count reaches zero), the upstream is unsubscribed. To accomplish this, the
UnicastSubjecthad to be retrofitted with a new optional callbackAction0which gets called at most once whenever eitheronErrororonCompletedis called or when the singleSubscriberunsubscribes.A secondary issue was with the
TestSubscriber's initial request; some upstream operators could get triggered withLong.MAX_VALUEdespite the initial request amount was set. This PR changes it to be set at construction time instead of inonStart.