2.x: add ParallelFlowable.sequentialDelayError#5117
Merged
akarnokd merged 3 commits intoReactiveX:2.xfrom Feb 21, 2017
Merged
Conversation
Codecov Report
@@ Coverage Diff @@
## 2.x #5117 +/- ##
===========================================
- Coverage 96% 95.97% -0.03%
- Complexity 5598 5609 +11
===========================================
Files 620 620
Lines 39699 39810 +111
Branches 5567 5597 +30
===========================================
+ Hits 38113 38208 +95
+ Misses 629 627 -2
- Partials 957 975 +18
Continue to review full report at Codecov.
|
JakeWharton
approved these changes
Feb 21, 2017
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 adds the
sequentialDelayErroroperator toParallelFlowablethat allows awaiting all 'rails' in a parallel flow to terminate normally or with the (composite) exception of the failed rail(s).To enable this, the
Flowable.parallel()operator's behavior regarding rail cancellation had to be changed. In v2.0.5 if any of the rails cancelled (maybe due to a failure, maybe due to an end consumer cancelling the entire parallel flow) the inputFlowablewas cancelled.This PR alters this by requiring all rails to cancel before cancelling the input
Flowable. The change permits one or multiple rails to fail and let others progress in case the newsequentialDelayErroris applied as a terminal operator. The originalsequential()operator still cancels all rails if one of them fails (triggering the cancellation of the inputFlowable).Note that this change may still drop and never process elements in the internal queues of the operators in the parallel flow (because the parallel processing is not implemented with work-stealing that could pick up elements from a dead queue). In order to get as many elements processed as possible, it is recommended to reduce the default prefetch on the
runOnoperator to a reasonable tradeoff value (between throughput and fault tolerance).Edit
Updated the PR to make sure
parallel()ignores cancelled rails when it dispatches items.Related: #5108.