refactor: multi subscriber adapter refactorings and fixes #1516
Conversation
…indowOp This was hidden in previous Mutiny releases as test ran with StrictMultiSubscriber between upstreams and AssertSubscriber. The operators would perform an overflow on negative requests.
This is cosmetic, but in theory a subscriber could request -1 then 5 elements, and then still receive onItem(n) signals.
The TCK randomly _and_ wrongly flags violations of rule 1.3 with the first onNext() signal happening while onSubscribe() hasn't finished yet.
This is especially useful for the operators that manage local demand.
Removes the cost of StrictMultiSubscriber when plugging non-Mutiny subscribers. This introduces MultiSubscriberAdapter, a very thin forwarding adapter between Flow.Subscriber and MultiSubscriber + ContextSupport. Note that StrictMultiSubscriber handled some pieces of the Reactive Streams protocol such as bad request(n) calls, upstream operators are not shielded on incomplete implementations anymore.
jponge
added
bug
|
@ozangunalp if you want to test against Reactive Messaging you will need https://github.com/jponge/smallrye-reactive-messaging/tree/scratchpad/mutiny-queues-refactor |
|
Yes I've that change from testing the jctools PR. |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1516 +/- ##
============================================
+ Coverage 89.23% 89.43% +0.20%
- Complexity 3270 3282 +12
============================================
Files 456 457 +1
Lines 13200 13264 +64
Branches 1622 1637 +15
============================================
+ Hits 11779 11863 +84
+ Misses 794 788 -6
+ Partials 627 613 -14
|
|
It should be quite transparent actually (famous last words 🤣 ) |
|
I might add a commit to address diff coverage |
Haven't checked the code but Reactive Messaging tests are OK. |
Thanks Ozan. A pass on the code would be appreciated, but only if you have time, otherwise I'll go ahead and merge |
No description provided.