[rabbitmq-discuss] acquiring channels per connection

[vorad]

Ok, my main concern about having one channel per application/tornado
instance is that I wouldn't know what's the request that corresponds to a
particular error when I catch it. That's the way I do it now (one channel
per application) and I still haven't figured things out on the error side.

Other than this it feels like adding another pool of objects to manage it's
not such a good idea so if I can stick with one connection and one channel
it would be great.

Thanks for your feedback.

On Wed, Mar 16, 2011 at 5:54 PM, Gavin M. Roy <gmr at myyearbook.com> wrote:

>
>  On Wednesday, March 16, 2011 at 11:42 AM, Marek Majkowski wrote:
>
> On Tue, Mar 15, 2011 at 07:11, vorad <vorad.1100 at gmail.com> wrote:
>
>  How expensive would be to do
> this (one channel per request) from the rabbitmq perspective and also from
> the Pika's perspective ?
>
>
> Well, not that expensive if your RabbitMQ is close to the web server.
> Opening channel is a synchronous action - a full roundtrip is required.
>
> To avoid that roundtrip you may hava a pool and reuse open channels.
>
> In addition, you're not buying anything by using more connections as
> they'll still use the same single process IOLoop.
>
> For what it'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.
>
> If you want to use multiple channels, I recommend having a sound reason for
> it. At the protocol level, it's nothing more than a numeric identifier for
> the frame routing. At the python level it's a set of two class instances
> which need to reside in memory. I can't think of a reason in my web
> applications that I would use more than one channel.
>
> For example, if you want to listen on multiple queues, just have multiple
> callbacks for channel.basic_consume.
>
> I guess my main point is using more channels and more connections doesn't
> offer any real value and adds additional overhead since you're bound to the
> same single process for responding to events.
>
> I would imagine if you could saturate a socket without saturating CPU that
> there could be some value, but offhand I can't imagine that is possible, as
> the OS's use of CPU would be saturated.
>
> Gavin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110322/a1bc8006/attachment.htm>