-
Notifications
You must be signed in to change notification settings - Fork 992
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
Decouple ConnectionWatchdog reconnect from timer thread #100
Labels
type: bug
A general bug
Milestone
Comments
mp911de
added a commit
that referenced
this issue
Jul 8, 2015
Motivation: Netty's HashedWheelTimer runs single threaded and processes, therefore, one task at a time. lettuce's ConnectionWatchdog uses a blocking call (without a timeout) to the initializing future that may block the timer thread indefinitely. The blocking call stops the reconnection for all connections because the processing thread is blocked.
mp911de
added a commit
that referenced
this issue
Jul 8, 2015
Motivation: Netty's HashedWheelTimer runs single threaded and processes, therefore, one task at a time. lettuce's ConnectionWatchdog uses a blocking call (without a timeout) to the initializing future that may block the timer thread indefinitely. The blocking call stops the reconnection for all connections because the processing thread is blocked.
mp911de
added a commit
that referenced
this issue
Jul 11, 2015
…t loop group) and honor timeouts when waiting for reconnects #100 Motivation: Performing connect tasks on the event loop can block the channel threads. In consequence, no further channel message processing is possible and threads run into a dead-lock situation. Reconnects are handled now in a own executor group not harming the channel's event loop. The reconnect futures use the connection's timeout for the whole reconnect sequence (TCP connect and initializations such as PING or SSL) to prevent infinite blocking.
mp911de
added a commit
that referenced
this issue
Jul 11, 2015
…t loop group) and honor timeouts when waiting for reconnects #100 Motivation: Performing connect tasks on the event loop can block the channel threads. In consequence, no further channel message processing is possible and threads run into a dead-lock situation. Reconnects are handled now in a own executor group not harming the channel's event loop. The reconnect futures use the connection's timeout for the whole reconnect sequence (TCP connect and initializations such as PING or SSL) to prevent infinite blocking.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Netty's
HashedWheelTimer
runs single threaded and processes, therefore, one task at a time. lettuce'sConnectionWatchdog
uses a blocking call (without a timeout) to the initializing future that may block the timer thread indefinitely. The blocking call stops the reconnection for all connections because the processing thread is blocked.Approach to fix:
The text was updated successfully, but these errors were encountered: