[rabbitmq-discuss] Rabbitmq 2.5-2.6.1 java hanging on close of connection
simon at rabbitmq.com
Mon Nov 21 13:07:10 GMT 2011
In general we do accept patches, although due to our Corporate Overlords
you would have to sign a contributor agreement.
I would be reluctant to merge such a patch though, since:
* It's to work around a server bug which will be fixed in the next release
* This bug has been around for most of a year without attracting much
* Option 1) is ugly; option 2) is (somewhat) complicated.
BTW, I got a reply from the spring-amqp maintainer, Dave Syer:
> Spring AMQP doesn't explicitly invoke close() in different threads.
> There's nothing to stop it happening (as is the case with the Java
> client itself I suppose), but we actually hardly ever call
> Channel.close() so it is pretty unlikely. I would be interested to
> hear of a way to tickle a normal app into this behaviour.
So I still wonder if the threading thing is something you are doing in
On 17/11/11 18:12, Benjamin Bennett wrote:
> Had a question if no one is working on patch for the java client do
> accept external patches?
> I was going to either change it to the following .
> 1) Remove the infinite wait on a connection close.
> Place a BlockingQueue on the channel closes during the close call.
> The sychronize on the BlockingQueue for the connection close , of
> which it cannot close the connection if a channel is currently be
> The second is more code but it would keep the infinity timeout in
> place will working around the deadlock issue.
> It would save a lot of pain if people are using 2.7.1 and below.
> On Mon, Nov 14, 2011 at 5:21 PM, Benjamin Bennett<benbennett at gmail.com> wrote:
>> I am using the spring amqp lib and it is doing the connection closing when
>> the spring context is closed. I do not think it has a property to inject the
>> hack. Also if you know any of the spring amqp devs. Having you telling them
>> to check to make sure it is doing the way you have described will have much
>> more authority than me.
>> I will probably hack the spring amqp lib for now
>> On Nov 14, 2011 12:32 PM, "Simon MacMullen"<simon at rabbitmq.com> wrote:
>>> On 14/11/11 16:15, Benjamin Bennett wrote:
>>>> Here is report from rabbitmqctrl report
>>> Ah, thank you. After some poking, that genuinely looks like a server bug.
>>> In order for it to happen you need the last channel close / close_ok to
>>> overlap with the connection close / close_ok. With the Java client you have
>>> to invoke Channel.close() and Connection.close() from different threads to
>>> get this to happen, and still be unlucky.
>>> You should be allowed to do this, but right now it's racy.
>>>> I was going to attempt to put a timeout on the connection close method
>>>> but that really would be a hack.
>>> Indeed! Other slightly less hacky workarounds until we get this fixed:
>>> * Invoke Channel.close() and Connection.close() from the same thread, or
>>> otherwise ensure they don't overlap.
>>> * Don't invoke Channel.close() if you know you're going to invoke
>>> Connection.close() anyway.
>>> Cheers, Simon
>>> Simon MacMullen
>>> RabbitMQ, VMware
>>> rabbitmq-discuss mailing list
>>> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss