<div dir="ltr">We actually do one connection per running application (JVM), with-in that JVM each "thread" gets it's own channel. This works rather well in web based contexts for us. When we have synchronous ordered message requirements, we use a single rabbit queue and server, with a publish directly to that queue/server, and a consume from the same one (not terribly ideal but it seems to be working).<div>
Jason</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 4:19 PM, Laing, Michael <span dir="ltr"><<a href="mailto:michael.laing@nytimes.com" target="_blank">michael.laing@nytimes.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi <span style="font-family:arial,sans-serif;font-size:13px">François,</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I didn't see anyone else respond so I can tell you what we do.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">There are lots of Quality of Service parameters set at the channel level. Since we have a moderate and stable collection of long-lived queues/exchanges, and long-lived connections for publishing/consuming, we typically use a channel per, to allow flexibility re QoS.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">One general rule is that a channel should be handled by only one thread. We use asynch event loop processing so it is normally not an issue for us but it may be for you.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">For asynch RPC functionality we set up a reply_to queue and use the correlation_id to disambiguate responses. Some people allocate a temporary queue for this purpose - if you use that model, you would probably want the temp queues in the same channel and they would then share the QoS parameters.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Hope this helps,</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Michael</font></div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 4:03 PM, François Beausoleil <span dir="ltr"><<a href="mailto:francois.beausoleil@gmail.com" target="_blank">francois.beausoleil@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm currently using two connections to RabbitMQ: one for consumers, one for publishers. This is to prevent throttling when the RabbitMQ instance triggers it's memory alarm.<br>
<br>
What about using channels? One channel per connection, or one channel per queue/exchange, or a mix? I realize this is similar to the green thread vs os threads in managed VMs. Are there advantages of one over the other?<br>
<br>
Thanks,<br>
François Beausoleil<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>
</blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Jason McIntosh<br><a href="http://mcintosh.poetshome.com/blog/">http://mcintosh.poetshome.com/blog/</a><br>573-424-7612
</div>