You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
For now, we are using lettuce to handle large scales of traffic. The traffic that comes to REDIS cluster per minute is more than 10 million per minute. In this situation, there are some cases where REDIS went down abruptly with various reasons(hardware failure, instance restart etc). The problem that we are facing is when the restarted REDIS instance is attached to REDIS cluster, there are a big CPU spikes causing latency spikes. It turns out that when REDIS instance goes back to REDIS cluster, lettuce client try to send the failed command to the recovered REDIS INSTANCE using AT LEAST ONCE mode of reliability. After changing auto reconnect mode to false,
the latency spike problem is gone. But, another problem that we have is we cannot reconnect that recovered REDIS instance. This is because only way to change reliability is to change auto connect mode. So, my suggestion/question is
why can't we set the only reliability level regardless of auto connect mode?
Is there any reason why reliability level should follow the auto reconnect mode?
A clear and concise description of what the problem is. Ex. I have an issue when [...]
Describe the solution you'd like
I want to suggest that if we can adjust the reliability level creating another option like RELIABILITY.
That can solve my problem.
A clear and concise description of what you want to happen. Add any considered drawbacks.
For now, I didn't understand why this RELIABILITY has to follow the auto reconnect mode.
The text was updated successfully, but these errors were encountered:
Feature Request
Is your feature request related to a problem? Please describe
For now, we are using lettuce to handle large scales of traffic. The traffic that comes to REDIS cluster per minute is more than 10 million per minute. In this situation, there are some cases where REDIS went down abruptly with various reasons(hardware failure, instance restart etc). The problem that we are facing is when the restarted REDIS instance is attached to REDIS cluster, there are a big CPU spikes causing latency spikes. It turns out that when REDIS instance goes back to REDIS cluster, lettuce client try to send the failed command to the recovered REDIS INSTANCE using AT LEAST ONCE mode of reliability. After changing auto reconnect mode to false,
the latency spike problem is gone. But, another problem that we have is we cannot reconnect that recovered REDIS instance. This is because only way to change reliability is to change auto connect mode. So, my suggestion/question is
why can't we set the only reliability level regardless of auto connect mode?
Is there any reason why reliability level should follow the auto reconnect mode?
A clear and concise description of what the problem is. Ex. I have an issue when [...]
Describe the solution you'd like
I want to suggest that if we can adjust the reliability level creating another option like RELIABILITY.
That can solve my problem.
A clear and concise description of what you want to happen. Add any considered drawbacks.
For now, I didn't understand why this RELIABILITY has to follow the auto reconnect mode.
The text was updated successfully, but these errors were encountered: