Hi Emilie,<br><br>thanks a lot for your comments. <br><br>One thing you pointed out called my attention:<br><br>"I would expect it to be more convenient for you to have an AMQP client
in each JVM and therefore use a connection per JVM. AMQP connections are
cheap resources and you need not try to conserve them. Brokers with
tens of thousands of connections are not unheard of."<br><br>This is the way I started implementing, and in each JVM I can have multiple consumers and producer, so I was thinking about have 1 connection per JVM with one channel per producer/consumer. I like the idea of separate producers and consumers.<br>
<br>As the project goes, I will update the list with question/comments.<br><br>Best Regards,<br><br><div class="gmail_quote">On Wed, Dec 22, 2010 at 3:41 PM, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com">emile@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;"><br>
Hi Thadeu,<br>
<br>
Your project sounds interesting. If I understand your question correctly you want to know if you should be using one connection with many channels, or many connections each with a single channel.<br>
<br>
A possibly relevant consideration is that if the broker needs to apply backpressure because of an overactive producer then all the channels sharing a connection with that producer will be blocked. Channels that can't tolerate this risk should have a connection to themselves. For the same reason you may want to separate producers and consumers to use different connections.<br>
<br>
I would expect it to be more convenient for you to have an AMQP client in each JVM and therefore use a connection per JVM. AMQP connections are cheap resources and you need not try to conserve them. Brokers with tens of thousands of connections are not unheard of.<div>
<div></div><div class="h5"><br>
<br>
On 19/12/10 13:20, Thadeu Russo 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,<br>
<br>
I need to architect a Java application using rabbitmq as its message<br>
broker. It is a distributed application and the message broker will play<br>
the role of connect the JVMs. Basically, each JVM has sets of objects<br>
(currently they are grouped by host:port) that can change messages to<br>
other objects in other groups in other virtual machines (there is a 1:1<br>
bi-directional relationship between groups of objects in different JVMs).<br>
The idea of use the broker is to avoid the number of tcp ports I have to<br>
open and also to take advantage of the message delivery guaranties.<br>
<br>
The design is simple: each group of objects will have an exchange and 2<br>
queues (incoming and outcoming) to change messages.<br>
<br>
I would like to know if you guys advise the following configuration<br>
regarding rabbitmq:<br>
<br>
1- Have 1 connection per JVM<br>
2- Have multiple channels to that connection. Each channel will be<br>
associated with those 2 queues<br>
<br>
What is concerning me is: the number of sends/receives per channel is<br>
high (about 5k/second). Should I have multiple connections (like a<br>
pool), or it is ok to use just 1 connection? If I have a pool of<br>
connections, I understand they will share the same tcp port, and I could<br>
not see any difference in using a single Connection.<br>
</blockquote>
<br></div></div>
The broker port will be same for each of multiple connections, but the peer port will typically be random. The difference is that connections with a single channel can fail and block without affecting other connections.<br>
<br>
Regards<br><font color="#888888">
<br>
Emile<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Thadeu de Russo e Carmo<br><a href="http://www.thadeu.com.br/">http://www.thadeu.com.br/</a><br><a href="http://www.caelum.com.br/">http://www.caelum.com.br/</a><br>
<a href="http://www.caelumobjects.com/">http://www.caelumobjects.com/</a><br>