[rabbitmq-discuss] Confirm consistent hash exchange behavior
simon at rabbitmq.com
Mon Mar 18 10:20:25 GMT 2013
Thanks for explaining your use case!
Of course, the whole point of the hashing part of the CHX is to ensure
that the broker does not need to maintain a routing key -> queue
mapping. It sounds like your case would require that. Which is not an
inconceivable thing to do, but it would mean we would need to think
about how that mapping can be prevented from constituting a memory leak.
I assume that you see new GUIDs quite frequently; is there a point at
which you know you won't see a certain GUID again? Or can you say
something like "if I haven't seen a certain GUID for 5 min, we can
forget about it?"
On 16/03/2013 12:17AM, SteveO wrote:
> Thanks all for the feedback.
> I'm not certain how to handle my basic "elastic scale up" scenario. That
> would be where I have 4 queues bound to the CHX, and my consumers aren't
> keeping up. I add a 5th without removing any of the other 4. I think that is
> a condition where I could wind up with messages with the same routing key in
> multiple queues.
> Our application will have producers sending messages with new GUIDs in the
> routing key throughout the course of any given day. The frequency of just
> how many new GUIDs over a set duration of time will vary throughout the
> course of the day. Business hours would have more new GUIDs than
> off-business hours, for example. That's why I thought it would be in my best
> interest to have a mechanism for scaling up and down. That just gets really
> tricky when I have that "must process everything in order" requirement.
> View this message in context: http://rabbitmq.1065348.n5.nabble.com/Confirm-consistent-hash-exchange-behavior-tp25458p25478.html
> Sent from the RabbitMQ mailing list archive at Nabble.com.
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss