RedisClusterClient unable to read partition information and results in ConcurrentModificationException #333
Comments
All non-threadsafe access to Partitions is now synchronized. Functional blocks that change the state of Partitions are grouped into atomar blocks that prevent reads to stale data and reads of partially updated data.
All non-threadsafe access to Partitions is now synchronized. Functional blocks that change the state of Partitions are grouped into atomar blocks that prevent reads to stale data and reads of partially updated data.
|
Thanks for your bug report. The periodic topology refresh performs in your case an update each 60 seconds. You have also the adaptive topology update configured that determines based on Redis responses whether to update the topology. In fact, the adaptive update is the better one as it updates the topology only on demand. I propose to raise the periodic update to 1-2 hrs or get rid of it at all. I deployed a fixed snapshot ( |
|
Hey, we tested with |
|
Do you have a bit more of the stack trace? It shows that |
|
That is the full length of the stack trace - 3 lines of our internal calls. Looks like the |
|
Thanks for the update. I wasn't able to reproduce the issue so far (single/multithreaded connection usage) so it's somewhat cumbersome to nail down the cause. I'm not sure whether synchronizing access to |
…tes #333 Partitions now uses a cached read-view for query/read operations. This is to decouple updates to Partitions. The most common case, iteration over Partition is now consistent with the state at which the iterator was obtained. The iterator and its content do not change during partition updates.
|
I changed |
|
Hey, we just ran with the initial config again with the new |
|
Great to hear that. Closing that ticket. Bugfix will be shipped with 4.2.2, scheduled for Aug, 19. |
…tes #333 Partitions now uses a cached read-view for query/read operations. This is to decouple updates to Partitions. The most common case, iteration over Partition is now consistent with the state at which the iterator was obtained. The iterator and its content do not change during partition updates.
Hey,
we are using the
RedisClusterClientin our setup and encountered several variations of those two errors:see [stacktrace1]
see [stacktrace2]
and
see [stacktrace3]
This is our configuration / connection code which seems to be the issue:
And we pinned it down to that marked line:
Without that line we don't experience any of the above exceptions.
The actual redis command that triggers those exceptions is a
hkeys:Our use case is quite simple - we only use
hmset,hkeys,hdelin that order.tldr;
For
RedisClusterClientsetting theClusterTopologyRefreshOptionswithenablePeriodicRefresh(60, TimeUnit.SECONDS)results inConcurrentModificationExceptionandCannot determine a partition to read for slotexceptions.Stacktraces
[stacktrace1]
[stacktrace2]
[stacktrace3]
The text was updated successfully, but these errors were encountered: