[rabbitmq-discuss] Confirm consistent hash exchange behavior

Mon Mar 18 10:42:15 GMT 2013

Why then not just have one queue per GUID and use the anon exchange to do
the routing? Then remove the queue when the GUID is not needed anymore.

Or here are we talking about of mapping several GUIDs to the same queue?

BTW, for a use case similar to this one is why I proposed the interval
exchange.

Regards,

Alvaro

On Mon, Mar 18, 2013 at 11:20 AM, Simon MacMullen <simon at rabbitmq.com>wrote:

> 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<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<rabbitmq-discuss at lists.rabbitmq.com>
>> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>>
>>  ______________________________**_________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130318/eaa27068/attachment.htm>