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
{{ message }}
This repository was archived by the owner on Jul 9, 2024. It is now read-only.
Only relevant for some use cases post-3.8.4 which has moved
plugin activation to a later point in the boot cycle, after
topology recovery.
Previously this state was naturally recovered during the topology
recovery boot step.
Closes#45.
Worth mentioning that this partially addresses #17. I'm not currently sure what would be a straightforward way to reconcile the needs of #17 and Jump consistent hashing's approach to ring population. But FWIW the ring repopulation now more stable/predictable w.r.t queue positions on the ring after first node restart.
michaelklishin
changed the title
Durable consistent hashing exchange cannot recover their previous state after node restart (3.8.4+)
Durable consistent hashing exchange cannot recover their previous state after node restart (3.8.4-specific)
Jun 15, 2020
Filing only for visibility, the actual behavior change is due to later plugin activation, see rabbitmq/rabbitmq-server#2381.
The text was updated successfully, but these errors were encountered: