[rabbitmq-discuss] Issue in Java client while fetching channel

Thu Aug 6 07:47:21 BST 2009

Ben,

>> As per the java client documentation, channel is not thread safe and I have multiple threads that would publish messages to the Q. For each publish, I create a new channel and publish the message.

> Yes, this is correct - channels are not thread safe. However, this doesn't mean you have to dispose of them every time you publish a message, all it means is that they shouldn't be shared across threads.
One way to achieve this is to store the channel in the ThreadLocal.

I am using web application to receive requests from clients. Each request would arrive as a separate thread and hence I cannot reuse the channel so it makes no sense in storing them. However, in case of consumer, I have created only one channel object and I do reuse this channel.

>> If you are aware of any other case where we may end up getting a null channel, then please let me know.

> As it turns out, there is actually a bug in the channel number allocation method that under some circumstances leads to a null channel being returned. This appears to be a bug in the HotSpot compiler (as the attached test proves on some JDKs - I was able to reproduce it on 1.6.0_14 on 64 bit Linux, but not on OSX or Windows).
The simple solution in the Java client is instead of comparing the max channel against Integer.MAX_VALUE, compare against Integer.MAX_VALUE - 1, and then the compiler doesn't seem to bin the loop. So I'll raise a bug for that and push the fix out.

I hope closing the channel as I am doing should suffice here. 
If this is not the case, I can even close the connection as soon as I detect that the channel being returned is null and reconnect. 
Please let me know if these are not the cases.

Thank you for your quick investigation and reply. Please keep me posted on the status of this bug.

Regards,
Anand Ved | Xoriant Solutions Pvt. Ltd. 
Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. 
Tel: +91 22 30511000 | +91 22 3051 1058 (Direct) | VOIP: + 1 408 834 4495  
Yahoo IM: anandved  | http://www.xoriant.com  
Modern technology, Owes ecology, An apology. ~Alan M. Eddison - Go Green!!

-----Original Message-----
From: Ben Hood [mailto:0x6e6562 at gmail.com] 
Sent: Wednesday, August 05, 2009 4:58 PM
To: Anand Ved
Cc: rabbitmq
Subject: Re: [rabbitmq-discuss] Issue in Java client while fetching channel

Arnand,

On Wed, Aug 5, 2009 at 2:24 AM, Anand Ved<anand.ved at xoriant.com> wrote:
> As per the java client documentation, channel is not thread safe and I have multiple threads that would publish messages to the Q. For each publish, I create a new channel and publish the message.

Yes, this is correct - channels are not thread safe. However, this doesn't mean you have to dispose of them every time you publish a message, all it means is that they shouldn't be shared across threads.
One way to achieve this is to store the channel in the ThreadLocal.

> Earlier I was not closing the channel and this lead to connection.createChannel() returning null object. Now as per java client document again, it is stated that if there are no channels available or if the current channel number is currently in use, then it would return null. Hence now I have closed the channel after each publish.

On the server side, there is no maximum number of channels per se.
This is only limited by the maximum number of processes in the Erlang VM, which is 32768 by default, but this can be raised to any number you like.

> If you are aware of any other case where we may end up getting a null channel, then please let me know.

As it turns out, there is actually a bug in the channel number allocation method that under some circumstances leads to a null channel being returned. This appears to be a bug in the HotSpot compiler (as the attached test proves on some JDKs - I was able to reproduce it on 1.6.0_14 on 64 bit Linux, but not on OSX or Windows).
The simple solution in the Java client is instead of comparing the max channel against Integer.MAX_VALUE, compare against Integer.MAX_VALUE - 1, and then the compiler doesn't seem to bin the loop. So I'll raise a bug for that and push the fix out.

HTH,

Ben