3.x: Fix concurrent clear() calls when fused chains are canceled #6676
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.
When a fuseable source backed by an SpscLinkedArrayQueue is cancelled and cleared concurrently (i.e., one thread clears while the other cancels the chain), the
clear()
method could run concurrently and either crash with NPE or end up in an infinite loop due to corrupted queue state.This PR fixes two kinds of mistakes leading to this scenario:
clear()
fromcancel
/dispose
when the output is fused.clear()
from a fused drain loop when cancellation is detected.When fused, similar to
poll()
, callingclear()
is the responsibility of the consumer and the producer side is not allowed to call them.The bug affected the following operators:
FlowableOnBackpressureBuffer
FlowableGroupBy
UnicastProcessor
UnicastSubject
Fixes #6673