5 Replies Latest reply on Apr 21, 2011 3:00 PM by vmiharia

    MessageConsumer.receive(timeout) return null

      I am not getting messages back when I use MessageConsumer.receive(timeout) method. I am trying to find out a way to diagnose the problem.

      Environment Setup
      Glassfish version 2.1

      com.sun.messaging.jmq Version Information Product Compatibility Version: 4.3 Protocol Version: 4.3 Target JMS API Version: 1.1

      Cluster set up using persistent storage.

      In the broker log, I see few of

      12/Apr/2011:20:58:22 EEST] [B1066]: Closing: admin@>jms:49519 because "[B0059]: Client closed the connection". Count: service=0 broker=8
      [12/Apr/2011:21:13:22 EEST] [B1066]: Closing: admin@>jms:49519 because "[B0059]: Client closed the connection". Count: service=0 broker=7

      Can somebody explain what is the count for service and broker ?

        • 1. Re: MessageConsumer.receive(timeout) return null
          The count for 'service=' and 'broker=' should be the connection counts for the service and the broker respectively. However the count for 'service=' in the log message is incorrect (http://java.net/jira/browse/MQ-83) which has been fixed in MQ 4.6.

          When using MessageConsumer.receive(timeout) to receive a message, it will return null if the message is not arrived in the client runtime within the timeout. The first thing to look at is whether the timeout value is long enough or whether repeated receive(timeout) will eventually receive the message. 4.3 is old. The latest release is 4.5. You may want to look if any bugs that have been fixed in later releases applicable to your case, for examples 6961586, 6972137.
          1 person found this helpful
          • 2. Re: MessageConsumer.receive(timeout) return null
            Sorry for the delayed response. I was out of office for the week.

            Thanks for your response.

            The system is in production, so I cannot upgrade the MQ . As I will have to upgrade glassfish to upgrade MQ, I don't want to take that drastic change in production servers.

            Currently, the problem I see is that even though there are messages available in the queues, the consumer does not come back with any messages. As I said, I was using MessageConsumer.recieve(timeout) method. But, once I send in more messages to the existing queues, it starts draining again. It almost seems that the broker goes to sleep, and wakes up once more messages gets in.

            Does it make any sense ?

            • 3. Re: MessageConsumer.receive(timeout) return null
              Nigel Deakin-Oracle
              Can you give some more information about the circumstances in which messages cease to be received? Are you saying that with, say x messages on the queue, the consumer receives y messages but then no more?

              Are you using a message selector?

              As AK said, 4.3 is quite an old version and there have been some fixes in this area and I too would advise you to try the latest version.

              Do you have a GlassFish support licence? If so then Oracle support will be able to help you, even with the older version you are running.

              • 4. Re: MessageConsumer.receive(timeout) return null
                You are RIGHT !

                bug 6961586 sounds very similar to what I am seeing, except I found I can restart the drainers by putting in more messages. I am not sure if that points to a different problem or just another work around.

                But it seems I cannot upgrade to MQ 4.5 without upgrading glassfish to 3.1, which seems weird given Glassfish can be integrated with other MQ providers .

                • 5. Re: MessageConsumer.receive(timeout) return null
                  I am running a high load. The queues had around 200,000 messages. I had two drainers continuously draining without any message-selector. But after 40,000 messages drainers keep returning with 0 messages. 'imqcmd query dst' showed another 160000 messages in the queue.

                  I sent 1000 more messages in the queues, and then it started draining again, and drained rest of the messages.

                  I am not sure what's causing that..