[rabbitmq-discuss] Confirm consistent hash exchange behavior

[Simon MacMullen]

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?"

Cheers, Simon

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.
>
> s
>
>
>
> --
> 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
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>