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
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.
public ClusterTopology getTopology() {
if (cached != null && shouldUseCachedValue()) {
return cached;
}
Map<String, Exception> errors = new LinkedHashMap<>();
List<Entry<String, ConnectionPool>> list = new ArrayList<>(cluster.getClusterNodes().entrySet());
Collections.shuffle(list);
for (Entry<String, ConnectionPool> entry : list) {
try (Connection connection = entry.getValue().getResource()) {
time = System.currentTimeMillis(); // time value is updated before cached object
Set<RedisClusterNode> nodes = Converters.toSetOfRedisClusterNodes(new Jedis(connection).clusterNodes());
cached = new ClusterTopology(nodes);
return cached;
} catch (Exception ex) {
errors.put(entry.getKey(), ex);
}
}
StringBuilder stringBuilder = new StringBuilder();
for (Entry<String, Exception> entry : errors.entrySet()) {
stringBuilder.append(String.format("\r\n\t- %s failed: %s", entry.getKey(), entry.getValue().getMessage()));
}
throw new ClusterStateFailureException(
"Could not retrieve cluster information; CLUSTER NODES returned with error" + stringBuilder);
}
The text was updated successfully, but these errors were encountered:
mp911de
changed the title
Race condition in org.springframework.data.redis.connection.jedis.JedisClusterConnection.JedisClusterTopologyProvider
Race condition in JedisClusterTopologyProviderSep 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
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
Original Pull Request: #2989
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: