Hi<div><br></div><div>Sorry to hijack this topic, but I'm pretty interested in the topic name Emile gave in the examples.</div><div>It looks like the topic is named from big to small. i.e. bigger topic comes first then dot then smaller ones.</div>
<div>Is there a specific reason behind this naming convention?</div><div>like in routing performance perspective? is it better than the other way around?</div><div>If for example, we have big�medium�and small, and there is a binding for "big every thing" is "big.#" better than "#.big" ?</div>
<div><br></div><div>-Stone</div><div><br><div class="gmail_quote">On Wed, Jul 18, 2012 at 1:23 PM, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="im"><br>
On 18/07/12 06:41, Bhaskar teja wrote:<br>
> What is a good design pattern for our use case - like number of queues?,<br>
> exchange type?, number of exchanges( web, e-mail ) ??<br>
<br>
</div>This looks like a potential application of topics and a topic exchange.<br>
Allocate a queue for each user. Bind each user queue with appropriate<br>
routing keys. So a queue for user "alice" belonging to two communities<br>
might have these bindings:<br>
<br>
users.alice<br>
communities.pet-owners<br>
communities.music-collectors<br>
<br>
When "alice" takes an action that her communities may be interested in<br>
then a message must be sent to the topic exchange with a routing key for<br>
each of the communities that she belongs to. It is possible to do this<br>
in a single operation using CC routing. See<br>
<a href="http://www.rabbitmq.com/extensions.html#sender-selected-distribution" target="_blank">http://www.rabbitmq.com/extensions.html#sender-selected-distribution</a><br>
<br>
Depending on the complexity of when groups are notified you could<br>
implement groups as sub-topics, so a group within pet-owners might be:<br>
<br>
communities.pet-owners.dog-lovers<br>
<br>
Depending on the rules for email notifications you could use a<br>
combination of dead letter exchanges and queue-TTL to detect when<br>
notifications have been waiting in the queue for too long and send them<br>
to the user by email. See:<br>
<br>
<a href="http://www.rabbitmq.com/extensions.html#dead-letter-exchanges" target="_blank">http://www.rabbitmq.com/extensions.html#dead-letter-exchanges</a><br>
<a href="http://www.rabbitmq.com/extensions.html#queue-ttl" target="_blank">http://www.rabbitmq.com/extensions.html#queue-ttl</a><br>
<br>
A possible problem with this design is the large number of bindings<br>
involved. This could be slow and difficult to manage, depending on the<br>
branching factor. You could contain the complexity by using<br>
exchange-to-exchange bindings and internal exchanges for groups (and<br>
communities).<br>
<br>
-Emile<br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br></div>