<div dir="ltr">Thanks Michael, Tim. great answers.<div><br></div><div>One more channel question:</div><div><br></div><div>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?</div>
<div><br></div><div>Thanks</div><div>Mike</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 23, 2013 at 11:40 AM, Tim Watson <span dir="ltr"><<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 23 Sep 2013, at 11:20, Mike Hadlow wrote:<br>
<br>
> Hi All,<br>
><br>
> 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?<br>
><br>
<br>
</div>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.<br>
<div class="im"><br>
> 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?<br>
><br>
<br>
</div>One problem you might run into relates to the answer I've given below about correlating ACKs with the correct channel.<br>
<div class="im"><br>
> Additional questions:<br>
><br>
> 1. Should each basic consume be invoked on a dedicated channel?<br>
><br>
<br>
</div>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.<br>
<div class="im"><br>
> 2. Do I need to basic.ack on the same channel on which I invoked basic.consume?<br>
><br>
<br>
</div>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.<br>
<br>
Cheers,<br>
Tim<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br></div>