[rabbitmq-discuss] unsynchronized access to com.rabbitmq.client.impl.AMQChannel#_blockContent in java client

[Matthew Sackman]

Hi Anton,

On Thu, Sep 23, 2010 at 12:40:19PM +0400, mabrek wrote:
> I use Channel.basicPublish() in http request handler (java client 2.1.0).
> Messages should be sent immediately or exception should be thrown
> after rabbitmq server had sent channel.flow active=false. If I don't
> handle channel.flow status, basicPublish() will hang until server
> sends channel.flow active=true.

That suggests that whilst you're using the client 2.1.0, you're not
using the broker 2.1.0 - the broker no longer sends channel.flow events
to the client - it simply relies on TCP backpressure to block clients
when the broker's under too much pressure. It is true that in the Java
client, when the broker is refusing publishes, the publish method in the
client will block. We have a bug open to try and figure out what we
could do here.

> I'm trying to check channel flow status before sending messages. It
> seems that the proper way to do it is to check
> channel.getFlow().getActive() but
> com.rabbitmq.client.impl.ChannelN#getFlow uses unsynchronized access
> to field _blockContent. Access to _blockContent is protected by
> synchronized (_channelMutex) in all other places.

That is a flawed approach as 1. we don't use channel.flow any more
anyway; 2. even if we did, what you propose is racey as the channel
could become blocked between you checking the status of the channel and
trying to publish.

Really, you need to make your application asynchronous and perhaps
buffer messages internally so that should a publish block, the rest of
your application can carry on regardless.

Matthew