Durable consistent hashing exchange

[ppilev]

hello,

I have question concerning x-consistent-hash exchange

Is it correct that after the node restart given routing key might be bound to another queue? a ref to the node restart effects
also I assume we're talking about rabbitmq server restart and not the client's node.

I ask this in relation with rabbitmq-consistent-hash-exchange/issues/32 and rabbitmq-consistent-hash-exchange/issues/45
so if we have durable queues and the topology doesn't change does that imply after restart the routing key should route to the same queue?

thanks.

[michaelklishin]

It depends on what clients do. In general, that exchange type does not guarantee routing key to queue stickiness. I thought we even had a doc note about that.

Any binding changes between client restarts can result in a reshuffling of the hash ring.

[stkrp]

Sorry for necroposting, but unfortunately I didn't fully understand your answer. Could you please describe the conditions under which hash ring stability is guaranteed? Or, conversely, that stability is impossible under any circumstances.

Relative positioning of queues on the ring is not guaranteed to be the same between restarts.

The documentation doesn't specify conditions under which the hash ring can remain the same, meaning it can't be relied upon. But what's the significant difference then from a "x-random" exchange in terms of race conditions? In both cases, messages must be ordered somehow on the receiving end. It's a completely different matter if race conditions need to be resolved only when the topology is updated.

1. If I change the binding of a completely different exchange, will it affect hash ring of the unchanged "x-consistent-hash" exchange?
2. If I don't change the bindings for the "x-consistent-hash" exchange, will this ensure that the hash ring is preserved after any node restart?
3. Is there a way to guarantee hash ring reproducibility for the "x-consistent-hash" exchange in a static topology? If not, are there any ways to avoid race conditions between the old and new queues?

I apologize if I seemed rude. I was simply trying to explain my confusion about choosing an exchange type. If there's no way to guarantee hash ring stability for a static topology between restarts, I plan to use modulo hashing on the sender side.

[michaelklishin]

@stkrp if the bindings do not change, neither will the hash ring. And if the hash ring is stable, so is the mapping of inputs to outputs, that is, mapping of messages to the bound queues (streams).

[stkrp]

@michaelklishin, thank you so much for such a lightning-fast response! This is exactly the kind of hash ring stability I needed.