Ok, my main concern about having one channel per application/tornado instance is that I wouldn&#39;t know what&#39;s the request that corresponds to a particular error when I catch it. That&#39;s the way I do it now (one channel per application) and I still haven&#39;t figured things out on the error side.<div>
<br></div><div>Other than this it feels like adding another pool of objects to manage it&#39;s not such a good idea so if I can stick with one connection and one channel it would be great.</div><div><br></div><div>Thanks for your feedback.<br>
<br><div class="gmail_quote">On Wed, Mar 16, 2011 at 5:54 PM, Gavin M. Roy <span dir="ltr">&lt;<a href="mailto:gmr@myyearbook.com">gmr@myyearbook.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
            <div><div class="im">
                <span>
                    <br>
                </span>
                <span></span>
                
                <p style="color:#a0a0a0">On Wednesday, March 16, 2011 at 11:42 AM, Marek Majkowski wrote:</p>
                </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
                    <span><div><div><div class="im">On Tue, Mar 15, 2011 at 07:11, vorad &lt;<a href="mailto:vorad.1100@gmail.com" target="_blank">vorad.1100@gmail.com</a>&gt; wrote:<br></div><div class="im"><blockquote type="cite">
<div>�How expensive would be to do<br>this (one channel per request) from the rabbitmq perspective and also from<br>the Pika&#39;s perspective ?<br></div></blockquote><br>Well, not that expensive if your RabbitMQ is close to the web server.<br>
Opening channel is a synchronous action - a full roundtrip is required.<br><br>To avoid that roundtrip you may hava a pool and reuse open channels.</div></div></div></span></blockquote><div>In addition, you&#39;re not buying anything by using more connections�as they&#39;ll still use the same single process IOLoop.</div>
<div><br></div><div>For what it&#39;s worth, I use Pika and Tornado with one connection and�channel per Tornado backend and hold on to the for the life of the backend, across multiple RequestHandler invocations.</div><div>
<br></div><div>If you want to use multiple channels, I recommend having a sound reason for it. At the protocol level, it&#39;s nothing more than a numeric identifier for the frame routing. At the python level it&#39;s a set of two class instances which need to reside in memory. I can&#39;t think of a reason in my web applications that I would use more than one channel.</div>
<div><br></div><div>For example, if you want to listen on multiple queues, just have multiple callbacks for channel.basic_consume.</div><div><br></div><div>I guess my main point is using more channels and more connections doesn&#39;t offer any real value and adds additional overhead since you&#39;re bound to the same single process for responding to events.</div>
<div><br></div><div>I would imagine if you could saturate a socket without saturating CPU that there could be some value, but offhand I can&#39;t imagine that is possible, as the OS&#39;s use of CPU would be saturated.</div>
<div><br></div><font color="#888888"><div>Gavin</div>
            </font></div>
        </div></blockquote></div><br></div>