[rabbitmq-discuss] Design question: the ratio of queues to channels

[Simon MacMullen]

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.

Cheers, Simon

>
> regards
> John
>
> 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
>
>
>
>


-- 
Simon MacMullen
Staff Engineer, RabbitMQ
SpringSource, a division of VMware