<div dir="ltr">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.<div style><br>Or here are we talking about of mapping several GUIDs to the same queue?</div>
<div style><br></div><div style>BTW, for a use case similar to this one is why I proposed the interval exchange.</div><div style><br></div><div style>Regards,</div><div style><br></div><div style>Alvaro</div><div style><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 18, 2013 at 11:20 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for explaining your use case!<br>
<br>
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.<br>
<br>
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?"<br>
<br>
Cheers, Simon<div class="HOEnZb"><div class="h5"><br>
<br>
On 16/03/2013 12:17AM, SteveO wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks all for the feedback.<br>
<br>
I'm not certain how to handle my basic "elastic scale up" scenario. That<br>
would be where I have 4 queues bound to the CHX, and my consumers aren't<br>
keeping up. I add a 5th without removing any of the other 4. I think that is<br>
a condition where I could wind up with messages with the same routing key in<br>
multiple queues.<br>
<br>
Our application will have producers sending messages with new GUIDs in the<br>
routing key throughout the course of any given day. The frequency of just<br>
how many new GUIDs over a set duration of time will vary throughout the<br>
course of the day. Business hours would have more new GUIDs than<br>
off-business hours, for example. That's why I thought it would be in my best<br>
interest to have a mechanism for scaling up and down. That just gets really<br>
tricky when I have that "must process everything in order" requirement.<br>
<br>
s<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://rabbitmq.1065348.n5.nabble.com/Confirm-consistent-hash-exchange-behavior-tp25458p25478.html" target="_blank">http://rabbitmq.1065348.n5.<u></u>nabble.com/Confirm-consistent-<u></u>hash-exchange-behavior-<u></u>tp25458p25478.html</a><br>
Sent from the RabbitMQ mailing list archive at Nabble.com.<br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
<br>
</blockquote>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>