[rabbitmq-discuss] QueueingConsumer basicPublish safety

Fri Jul 30 14:32:00 BST 2010

Hi Tsuraan,

On 29/07/10 17:11, tsuraan wrote:
>> Channel.flow has been asserted and therefore the basic.publish call has
>> blocked. We are aware that our API documentation is incorrect in
>> claiming that basic.publish is safe to use in the given context. This
>> will be updated.
> 
> So this probably only happens when rabbit thinks it's overloaded?

Correct

>> You need to enable consumption of messages while publishers are
>> potentially blocked. This will allow memory pressure on the broker to be
>> relieved and publishers to resume eventually. In your example
>> consumption and publication happens in the same thread and therefore
>> your application gets completely stuck as soon as publication blocks.
> 
> So is it safe to publish messages on a channel when some other thread
> is consuming on that channel?  If I acquire a lock on the channel in a
> different thread, and the channel blocks in basicPublish, will that
> still allow new messages to be delivered to the consumer?

In general, channels should not be shared by multiple threads, which is
what you are proposing. In your case it makes sense to publish and
consume on different channels to prevent this.

Even so, the channel.flow event from the broker that blocks the producer
only affects messages travelling in one direction. AMQP permits the
broker to deliver messages to consumer on the same channel.

>> You could also consider using separate channels for publishing and
>> consuming messages.
> I'm currently doing acks and publishes in a transaction, but I'm not
> sure if that's entirely necessary.  It's certainly convenient and
> safe, but I don't know that I really need to do it.  Are acks
> guaranteed not to block the way that publishes do?  I obviously can't
> send my acks on a different channel :)

Acks are guaranteed not to block.

Regards

Emile