BTW - Thanks for the article reference. That helped.<br><br>The only real disadvantage to AMQP is not monitoring<br>whether clients are present/active or not, and that<br>requirement is application specific.<br><br>- Jim<br>
<br>Jim Irrer <a href="mailto:irrer@umich.edu">irrer@umich.edu</a> (734) 647-4409<br>University of Michigan Hospital Radiation Oncology<br>519 W. William St. Ann Arbor, MI 48103<br>
<br><br><div class="gmail_quote">On Fri, Jan 28, 2011 at 7:51 AM, Jim Apperly <span dir="ltr"><<a href="mailto:jim@rabbitmq.com">jim@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im">On 27 January 2011 19:25, Jim Irrer <span dir="ltr"><<a href="mailto:irrer@umich.edu" target="_blank">irrer@umich.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Would XMPP be more appropriate for this application? I'm not real<br>familiar with it but I've heard that it has different strengths than AMQP.<br>I'm interested in the pros and cons.<br clear="all"></blockquote>
<div><br></div></div><div>This may help shed some light:</div><div><a href="http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/" target="_blank">http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/</a></div>
<div><br></div><font color="#888888"><div>Jim</div></font><div><div></div><div class="h5"><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Thanks,<br>
<br>- Jim<br><font color="#888888"><br>Jim Irrer <a href="mailto:irrer@umich.edu" target="_blank">irrer@umich.edu</a> (734) 647-4409<br>University of Michigan Hospital Radiation Oncology<br>519 W. William St. Ann Arbor, MI 48103</font><div>
<div></div><div><br>
<br><br><div class="gmail_quote">On Thu, Jan 27, 2011 at 10:06 AM, Michael Bridgen <span dir="ltr"><<a href="mailto:mikeb@rabbitmq.com" target="_blank">mikeb@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Kaiduan,<br>
<br>
Your questions suggest you're attempting something very interesting, which I would love to hear more about. Federation and distribution are very much on our minds here at Rabbit Towers, as you might imagine.<br>
<br>
In the meantime ---<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
1) Any user can subscribe to the interested topic, but only topic<br>
owner can publish message to the group. There is no limit on the<br>
number of subscribers in each group. Potentially it can be huge, for<br>
example, the fans of U2 around the world.<br>
</blockquote>
<br></div>
Is there anything that determines who can own topics? For example, is it just the first person to declare a topic that is the exclusive publisher to that topic? Can the publishing rights, so to speak, be handed to another publisher?<div>
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2) User including subscriber and publisher is not always connected to<br>
the system, and not always connected to the same node in the system,<br>
and the message delivery should be guaranteed. When publisher<br>
publishes a message, the system should deliver the message to all<br>
subscribers. If the subscriber is connected to the system, the message<br>
should be delivered immediately. If the subscriber is not connected,<br>
system should hold the message, and the next time the user comes<br>
connected, system will deliver the message to the user. Just imagine<br>
the user can be any mobile user and moves out of cellular coverage.<br>
</blockquote>
<br></div>
So far as I know, this is still an area of active research. Typically, distributed pub/sub systems like Scribe and Hermes give rather weak guarantees of delivery and ordering and so on.<br>
<br>
In particular, "If the subscriber is not connected, system should hold the message, and the next time the user comes connected, system will deliver the message to the user" is difficult if the subscriber can connect to any node, and I don't think most pub/sub systems would allow that.<div>
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
3) The system should be able to support tens to hundreds of millions<br>
users spreading around the world, so the system will consist hundred<br>
of nodes located in different physical locations.<br>
</blockquote>
<br></div>
This is rather ambitious. But systems on this kind of scale are indeed being built: <a href="http://ci.oceanobservatories.org/" target="_blank">http://ci.oceanobservatories.org/</a> for instance.<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
4) The number of topics/groups in the system is unlimited.<br>
<br>
5) As to the latency, it should be in the range of 1 minute if<br>
subscriber is connected.<br>
<br>
It looks like RabbitMQ already has functionalities to meet the above<br>
requirement, for example, fan out exchange, and persistent message.<br>
The following is my understanding on how to build the above system<br>
with RabbitMQ,<br>
</blockquote>
<br></div>
Perhaps, in the sense that it can be a building block. But it doesn't fulfill all the requirements you've given above, "out of the box". In other words, you (or we) would have to invent a substantial part of the technology.<div>
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
a) Publisher creates an exchange. For example, U2 creates an exchange<br>
noted as "U2" for "U2's next world wide tour" on Node 1.<br>
<br>
b) Each subscriber creates a queue in the system. For example, Alice<br>
creates a queue noted as "Alice" on Node 2 and binds to exchange U2;<br>
and Bob creates a queue noted as "Bob" on Node 3 and binds to exchange<br>
"U2" on Node 2.<br>
<br>
c) U2 publishes a message, m1 on Node 1 to exchange "U2"; and RabbitMQ<br>
will deliver the message m1 to queue "Alice" on Node 2 and to queue<br>
"Bob" on Node 3.<br>
<br>
How we handles the following scenarios?<br>
<br>
1) When U2 wants to publish a message, but Node 1 is done.<br>
<br>
2) When message m1 is delivered to queue "Alice" on Node 2, Node 2<br>
crashed or the network link between Node 1 (publisher's node) is<br>
disconnected? Will exchange "U2" on Node 1 persist the message?<br>
</blockquote>
<br></div>
No; the message will be lost so far as Alice is concerned. In AMQP terms, you're asking for queues to be replicated. Rabbit doesn't do this, yet.<br>
<br>
(Actually, we are working on queue replication right now. I think you would need both replication and some kind of queue migration or distribution.)<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
3) After message m1 is arrived on queue "Alice", but the connection<br>
between Alice and Node 2 is gone, the message will be stored on Node<br>
2, right? Next time, Alice connects to the system, but she is<br>
connected to Node n instead of Node 2, how to handle this?<br>
</blockquote>
<br></div>
In Rabbit's clustering as it works now, the messages will be delivered across the cluster to Node n.<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
4) What is the multi-cast technology used in RabbitMQ to deliver the<br>
message to queues located on different locations spreading around<br>
different countries?<br>
</blockquote>
<br></div>
There isn't any right now. Clustering is really for nodes that are co-located and have reliable connections. It uses Erlang's distribution mechanism, which essentially forms a fully-connected graph of nodes. It doesn't really scale beyond a handful of nodes.<br>
<br>
There /is/ a plugin called the "shovel", which will relay messages from one broker to another. However, it is statically configured, and constrained by using AMQP to do the relaying (i.e., you cannot tell it to relay all messages from a direct exchange; only to relay, e.g., messages with a particular routing key).<br>
<br>
<br>
Regards,<br><font color="#888888">
Michael</font><div><div></div><div><br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">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>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">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>
<br></blockquote></div></div></div><br>
</blockquote></div><br>