The .NET client user guide (v2.6.1) states that IModel should not be
shared between threads.

Apparently BasicAck must be called on the same channel on which the
message was received.

When asynchronously consuming messages with IBasicConsumer, is it safe
to call BasicAck on the original channel (created on the application
thread) in the handler without locking?

I'm assuming that the handler runs on the connection thread.

I realize that publish should not be called in the handler. If publish
can be called by the application thread, should that be done on a
separate channel from the consuming one?

(There's a similar question on the Java client here:
http://groups.google.com/group/rabbitmq-discuss/browse_thread/thread/6a0b05b598f308cf/cbbd7a0c9f9b4dd3?lnk=gst&q=channel+thread+ack#cbbd7a0c9f9b4dd3)

Search Discussions

  • Emile Joubert at Oct 13, 2011 at 12:35 pm
    Hi,
    On 12/10/11 20:29, TrueWill wrote:
    The .NET client user guide (v2.6.1) states that IModel should not be
    shared between threads.

    Apparently BasicAck must be called on the same channel on which the
    message was received.

    When asynchronously consuming messages with IBasicConsumer, is it safe
    to call BasicAck on the original channel (created on the application
    thread) in the handler without locking?
    Yes, asynchronous methods such as ack and publish are safe.
    I'm assuming that the handler runs on the connection thread.

    I realize that publish should not be called in the handler. If publish
    can be called by the application thread, should that be done on a
    separate channel from the consuming one?
    You can use publish from the same channel or from a separate channel.
    You must ensure that you do not invoke blocking methods (that wait for a
    reply from the broker) in a handler. QueueDeclare and BasicCancel are
    examples of methods that will cause deadlock.


    -Emile
  • TrueWill at Oct 13, 2011 at 4:17 pm
    Thank you for your response.

    I'm still confused, though. The rabbitmq-dotnet-client-2.6.1-user-guide
    states (p. 11):

    "Application callback handlers *must not* invoke blocking AMQP operations
    (such as
    IModel.QueueDeclare, IModel.BasicCancel or IModel.BasicPublish). If they do,
    the channel
    will deadlock."

    Could you please clarify?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111013/5c8f668e/attachment.htm>
  • Emile Joubert at Oct 13, 2011 at 5:15 pm
    Hi,
    On 13/10/11 17:17, TrueWill wrote:
    Thank you for your response.

    I'm still confused, though. The rabbitmq-dotnet-client-2.6.1-user-guide
    states (p. 11):

    "Application callback handlers /must not/ invoke blocking AMQP
    operations (such as
    IModel.QueueDeclare, IModel.BasicCancel or IModel.BasicPublish). If they
    do, the channel
    will deadlock."

    Could you please clarify?
    Yes. If you issue any synchronous commands from a handler then the
    channel will immediately deadlock. Publish could deadlock only if
    channel flow was asserted by the broker, but recent versions of the
    broker (since 2.0.0) use TCP back pressure instead of channel
    flow-control. If you want interoperability with other brokers that might
    use channel flow-control then you should avoid publish within a handler.

    Be aware that TCP back pressure will block asynchronous methods like
    ack, without causing the channel to deadlock, and back pressure affects
    all channels sharing the connection.

    The safest approach is to use the QueueingBasicConsumer with BasicQos to
    prevent the client from receiving too many messages at once.



    -Emile

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedOct 12, '11 at 7:29p
activeOct 13, '11 at 5:15p
posts4
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Emile Joubert: 2 posts TrueWill: 2 posts

People

Translate

site design / logo © 2022 Grokbase