New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ensures volatile connection is reset prior subscription cancellation #3707
base: 3.4.x
Are you sure you want to change the base?
Conversation
Signed-off-by: Oleh Dokuka <odokuka@vmware.com>
super(Flux.range(0, 1), 1, Duration.ofMillis(0)); | ||
} | ||
|
||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@OlegDokuka are you planning to arrange these comments still? If not, I can do so.
@Outcome(id = { | ||
"10, 10, 1, 1, 0, 0"}, expect = ACCEPTABLE, desc = "concurrent subscription succeeded") | ||
@State | ||
public static class RefCntGraceConcurrentSubscriptionRangeAsyncFusionStressTest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason why sync fusion is not tested for FluxRefCountGrace
?
r.r5 = subscriber1.onErrorCalls.get(); | ||
r.r6 = subscriber2.onErrorCalls.get(); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason why an error scenario is not tested for FluxRefCountGrace
?
This PR ensures that in case of racing between multiple subscribers we ensure that the potential outdated FluxReplay.connection which one of the subscribers can join while creating a different connection instance at the level FluxRefCnt is not causing a new FluxReplay.connection to be prematurely closed up on the previous connection instance replay all the values