Skip to content
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

Closed
mp911de opened this issue Jul 8, 2015 · 0 comments
Closed

Decouple ConnectionWatchdog reconnect from timer thread #100

mp911de opened this issue Jul 8, 2015 · 0 comments
Labels
type: bug A general bug
Milestone

Comments

@mp911de
Copy link
Collaborator

mp911de commented Jul 8, 2015

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.

Approach to fix:

  • Use a timeout
  • Perform the reconnect on the event loop group which provides more than one thread
@mp911de mp911de added the type: bug A general bug label Jul 8, 2015
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 mp911de closed this as completed Jul 8, 2015
@mp911de mp911de added this to the Lettuce 3.3 milestone Jul 8, 2015
@mp911de mp911de reopened this Jul 10, 2015
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.
@mp911de mp911de closed this as completed Jul 11, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

1 participant