-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Race condition in JedisClusterTopologyProvider
#2986
Comments
spring-projects-issues
added
the
status: waiting-for-triage
An issue we've not yet triaged
label
Sep 9, 2024
mp911de
added
type: bug
A general bug
and removed
status: waiting-for-triage
An issue we've not yet triaged
labels
Sep 9, 2024
mp911de
changed the title
Race condition in org.springframework.data.redis.connection.jedis.JedisClusterConnection.JedisClusterTopologyProvider
Race condition in Sep 11, 2024
JedisClusterTopologyProvider
mp911de
added a commit
that referenced
this issue
Sep 11, 2024
We now use a value object for caching the topology to avoid races in updating the cache timestamp. Also, we set the cache timestamp after obtaining the topology to avoid that I/O latency expires the topology cache. Closes #2986
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
JedisClusterTopologyProvider use a cache object to optimize performace on frequent cluster requests, but the time value is updated before the cache object, there is a race condition that the old cache including the invalid cluster topology might get returned, which will result in a ClusterCommandExecutionFailureException: Could not get a resource from th pool.
The text was updated successfully, but these errors were encountered: