-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Reactive stream spec violation when using command timeout #1576
Labels
Milestone
Comments
mp911de
added a commit
that referenced
this issue
Jan 12, 2021
We now ensure that CommandWrapper and its subclass SubscriptionCommand trigger only a single completion signal. Previously, a race could happen inside the completion notification which could cause a completion and error signal or error + completion because of improper guarding.
mp911de
added a commit
that referenced
this issue
Jan 12, 2021
We now ensure that CommandWrapper and its subclass SubscriptionCommand trigger only a single completion signal. Previously, a race could happen inside the completion notification which could cause a completion and error signal or error + completion because of improper guarding.
mp911de
added a commit
that referenced
this issue
Jan 12, 2021
We now ensure that CommandWrapper and its subclass SubscriptionCommand trigger only a single completion signal. Previously, a race could happen inside the completion notification which could cause a completion and error signal or error + completion because of improper guarding.
That's fixed now. |
We appreciate the really quick turnaround. Thank you @mp911de! |
The releases 6.0.2 respective 5.3.6 are now available from Maven Central |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Bug Report
Related issue: #1274
Current Behavior
When a
RedisCommandTimeoutException
happens it is possible (depending on CPU task scheduling) that the timeout error will be triggered after the underlying command is completed thus violating reactive spec. Futhermore, this error causes theDefaultEventExecutor
to terminate which leaves most subsequent Redis commands in a stuck state whenpublishOnScheduler(true)
.Stack trace
Input Code
https://github.com/martin-tarjanyi/lettuce-executor-reject-repro
Expected behavior/code
No violation of reactive stream spec, no terminated executor, no stuck Redis commands
Environment
Possible Solution
As pointed out by @mp911de
SubscriptionCommand
andCommandWrapper
do not ensure single completion. Fixing that will fix this issue.The text was updated successfully, but these errors were encountered: