[rabbitmq-discuss] Design question: the ratio of queues to channels
simon at rabbitmq.com
Tue Jul 13 15:09:45 BST 2010
On 13/07/10 15:01, John Goodson wrote:
> Hi Simon,
Hi John. Please keep the mailing list CCed, it helps other people learn.
> Yes I am using Ruby.
> Thanks for your response, it is clearer and you have been very helpful
> in that I can now see that my initial design choices are significantly
> less then optimal for the types of behavior I want.
Sure, no problem!
> Is my understanding correct take that a design constraint in creating
> channels is how many open sockets the Erlang server can support?
Well, channels are multiplexed onto TCP connections. A connection can
support up to 65535 channels on a single socket, so you should be OK. If
you need more channels, opening a second connection should be OK :)
Most client libraries make this fairly obvious, e.g. in Java:
Connection conn = new ConnectionFactory().newConnection();
Channel chan = conn.createChannel();
but the Ruby library doesn't make it immediately obvious what's going
on. It might be creating one channel per connection. Unfortunately I
don't know much about it.
> PS, ugh on having to figure out design/usage patterns based on reading
> the spec.
Indeed. You can always ask here though.
> On Tue, Jul 13, 2010 at 5:12 AM, Simon MacMullen <simon at rabbitmq.com
> <mailto:simon at rabbitmq.com>> wrote:
> Which approach is better and why?
> The primary things that channels do are:
> * Give scope to some errors
> * Give scope to consumers
> * Allow at most one operation at once
> So with your approach you run the risk that a soft error (e.g.
> not-found) will close the single channel and take down everything.
> This may or may not be a concern.
> Also, if your app is multithreaded it can still only perform one
> operation at once (although channels are not threadsafe in most
> clients anyway).
> Of course, neither of these may be a concern to you.
> Is that any clearer?
> > Are there any documents that I can
> > reference that give guidelines on this?
> The best thing is the spec. Yeah, I know. One of the items on our
> very long todo list is a comprehensive overview of AMQP...
> Cheers, Simon
Staff Engineer, RabbitMQ
SpringSource, a division of VMware
More information about the rabbitmq-discuss