-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Allow redis's connect and read/command timeouts to be configured separately #23137
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
Conversation
…perties; Fix Lettuce connection timeout See spring-projects#23070
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. Rather than introducing two new properties, let's reuse the existing one for read/command timeout.
Would you have time to review your proposal?
/** | ||
* Read timeout. | ||
*/ | ||
private Duration readTimeout; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than adding two now configuration properties, let's reuse the existing timeout for the read timeout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -67,10 +67,20 @@ | |||
private boolean ssl; | |||
|
|||
/** | |||
* Connection timeout. | |||
* Connection and read timeout. | |||
*/ | |||
private Duration timeout; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can see timeout
is not longer honoured, that's a problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used timeout
in getters if a more specific property was not set. But now it's not relevant anymore
...
public Duration getConnectionTimeout() {
return (this.connectionTimeout != null) ? this.connectionTimeout : this.timeout;
}
...
public Duration getReadTimeout() {
return (this.readTimeout != null) ? this.readTimeout : this.timeout;
}
....
}); | ||
@ParameterizedTest(name = "{0}") | ||
@MethodSource("timeoutArguments") | ||
void testRedisConfigurationWithTimeout(List<String> properties, long readTimeout, long connectionTimeout) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than a parametrised test, I think we can go with two tests. One that doesn't set anything and make sure defaults are properly honoured and one that sets both the timeout and the connect timeout and check the override has been customized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
}); | ||
@ParameterizedTest(name = "{0}") | ||
@MethodSource("timeoutArguments") | ||
void testRedisConfigurationWithTimeouts(List<String> properties, long readTimeout, long connectionTimeout) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same, I don't think a parameterized test is warranted here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@snicoll Thanks for your feedback. I'll make the changes today or tomorrow |
@anshlykov thanks for the follow-up. This is now merged in |
Fixes #23070