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

Adjusting disconnectedBehavior Option to Prevent Timeout During Redis Shutdown #2866 #2894

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

MagicalLas
Copy link

The purpose of this PR is to adjust the disconnectedBehavior option to prevent timeouts when Redis is shutdown, addressing issue #2866.

Make sure that:

  • You have read the contribution guidelines.
  • You have created a feature request first to discuss your contribution intent. Please reference the feature request ticket number in the pull request.
  • You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
  • You submit test cases (unit or integration tests) that back your changes.

… Shutdown

We often need to shut down Redis for maintenance, such as version upgrades. During these times, requests do not fail immediately but instead experience timeouts, increasing application latency. This issue can be resolved by adjusting some options.

Currently, our Redis client options are configured as follows:

```java
ClientOptions options = ClientOptions.builder()
.autoReconnect(true)
.disconnectedBehavior(DisconnectedBehavior.REJECT_COMMANDS)
```

The DisconnectedBehavior.REJECT_COMMANDS option appears to cancel commands when the connection is lost. However, if autoReconnect is not set to false, commands in the CommandHandler.stack are not canceled but are placed into the disconnectedBuffer. Therefore, ongoing commands are not rejected if autoReconnect is true, even with the client option modified.

For services heavily relying on Redis, latency is crucial. Additionally, we want to avoid writing custom code for reconnections by using the auto-reconnect feature. Adjusting the autoReconnect option can solve this issue immediately, but it would require significant changes to implement automatic reconnection.

Proposal

We propose that the condition for canceling commands in the CommandHandler.stack should be based solely on rejectCommandsWhileDisconnected and not combined with autoReconnect.

I've submitted a PR with a simple code change. Please let me know your thoughts.

===

Additionally our applications, to maintain low latency and avoid queuing many requests in the buffer when the connection is down, we have configured the client to execute commands only when the connection is active. As a result, only a few requests in the CommandHandler.stack encounter timeouts, but this still negatively impacts the application.
@tishun
Copy link
Collaborator

tishun commented Jul 2, 2024

Do you think you can also add a test that simulates the scenario you are fixing?

@tishun tishun added this to the 6.5.0.RELEASE milestone Aug 8, 2024
@tishun tishun added the type: feature A new feature label Aug 8, 2024
@tishun tishun added for: team-attention An issue we need to discuss as a team to make progress status: waiting-for-triage labels Sep 16, 2024
@tishun tishun modified the milestones: 6.5.0.RELEASE, 6.6.0.RELEASE Nov 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: team-attention An issue we need to discuss as a team to make progress status: waiting-for-triage type: feature A new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants