[rabbitmq-discuss] Channel best practices

[Mike Hadlow]

Thanks Michael, Tim. great answers.

One more channel question:

You shouldn't share a channel between multiple threads, but given that an
ACK should be sent on the same channel that the delivery is received mean
that one _must_ violate this rule? I call basic.consume on my application
thread, but basic.deliver will be called on the client library's internal
message loop thread and then the ACK will no doubt be called on a separate
application thread (where I de-queue the message from my queuing consumer).
Is this violation of the do-not-use-channels-on-multiple-threads rule OK?

Thanks
Mike


On Mon, Sep 23, 2013 at 11:40 AM, Tim Watson <tim at rabbitmq.com> wrote:

>
> On 23 Sep 2013, at 11:20, Mike Hadlow wrote:
>
> > Hi All,
> >
> > Are channel best practices for connected RabbitMQ clients published
> anywhere? I understand the threading limitations, that channels should not
> be shared between threads. Does the channel concept exist only to support
> multi-threaded applications, or does it have some other purpose?
> >
>
> The channel concept exists (in AMQP) to provide a lightweight alternative
> to having one TCP connection per client, since the latter are resource
> intensive (to both client and server's detriment). Multiplexing multiple
> "clients" over a single TCP connection turns out to be a fairly common
> approach amongst network intensive applications. Channels also provide a
> unit of atomicity with regards message ordering, i.e., messages are always
> fully (FIFO) ordered from client to server over a single channel, whereas
> there are no ordering guarantees regarding messages concurrently sent (or
> delivered) over multiple channels.
>
> > If I marshal all calls to a channel onto a single thread in my
> application code, is there any problem with simply maintaining a single
> channel for all declares, publishes and consumes?
> >
>
> One problem you might run into relates to the answer I've given below
> about correlating ACKs with the correct channel.
>
> > Additional questions:
> >
> > 1. Should each basic consume be invoked on a dedicated channel?
> >
>
> That's not strictly necessary, though neither is it wrong. Depending on
> your application logic, you might find that introduces unnecessary overhead
> (in terms of threads and associated synchronisation primitives used in the
> client and/or additional resource use on the server), so if I were you I
> would only do it if it is (a) necessary or (b) significantly simplifies
> your client code. Remember that a channel provides a FIFO ordering
> guarantee, so having multiple consumers on a single channel means that
> you're potentially dealing with messages from more than one source queue,
> in which case you might inadvertently introduce a serial bottleneck.
>
> > 2. Do I need to basic.ack on the same channel on which I invoked
> basic.consume?
> >
>
> Yes, that is absolutely necessary. An ACK sent on another channel to the
> one on which the delivery was received will be treated as a channel error.
>
> Cheers,
> Tim
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130923/3bc0b6ca/attachment.htm>