Hi,

I am facing a typical issue while fetching a channel from the connection
while using Java client.

In my code, I was utilizing a connection that is alive and fetching
channels by calling connection.getChannel();
While my application server was running for over 3 days, I found that
getting channel obj via calling connection.getChannel() would return
null.

Investigation lead to my not closing the channel after publishing a
message. And I have now closed the channel as soon as I publish.

Are there any other known scenarios where we would get the channel
object as null.

My connection params has requestedChannels as 0, requestedHeartbeat as
360 secs. Please suggest.

Regards,
Anand Ved | Xoriant Solutions Pvt. Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090805/e4bcddab/attachment.htm

Search Discussions

  • Ben Hood at Aug 4, 2009 at 10:31 pm
    Anand,

    On Tue, Aug 4, 2009 at 7:44 PM, Anand Vedwrote:
    Investigation lead to my not closing the channel after publishing a message.
    And I have now closed the channel as soon as I publish.
    Why do have to close the channel after you publish each message?

    Ben
  • Anand Ved at Aug 5, 2009 at 1:24 am
    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.

    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.

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

    Regards,
    Anand Ved | Xoriant Solutions Pvt. Ltd.?
    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:01 AM
    To: Anand Ved
    Cc: rabbitmq
    Subject: Re: [rabbitmq-discuss] Issue in Java client while fetching channel

    Anand,

    On Tue, Aug 4, 2009 at 7:44 PM, Anand Vedwrote:
    Investigation lead to my not closing the channel after publishing a message.
    And I have now closed the channel as soon as I publish.
    Why do have to close the channel after you publish each message?

    Ben
  • Ben Hood at Aug 5, 2009 at 11:28 am
    Arnand,

    On Wed, Aug 5, 2009 at 2:24 AM, Anand Vedwrote:
    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
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: HotSpotTest.java
    Type: text/x-java
    Size: 432 bytes
    Desc: not available
    Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090805/6a626618/attachment.java
  • Anand Ved at Aug 6, 2009 at 6:47 am
    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 Vedwrote:
    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
  • Ben Hood at Aug 6, 2009 at 10:14 am
    Anand,

    On Thu, Aug 6, 2009 at 7:47 AM, Anand Vedwrote:
    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.
    Are you using a web server that actually creates a new thread to
    handle each request?

    Although creating a channel for each request is not necessarily a
    major issue for Rabbit or the Java client, at some stage you might
    find some kind of pooling helpful, e.g. commons-pool.
    Thank you for your quick investigation and reply. Please keep me posted on the status of this bug.
    This is fixed and is awaiting QA. If you want the un-QA'ed fix, check
    out the branch called bug21333 from the repository. I'll put a note in
    the bug to inform the mailing list when this lands on default.

    Ben

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedAug 4, '09 at 6:44p
activeAug 6, '09 at 10:14a
posts6
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Anand Ved: 3 posts Ben Hood: 3 posts

People

Translate

site design / logo © 2022 Grokbase