5 Replies Latest reply: Dec 9, 2011 2:31 PM by Alex Corvino RSS

    JMS producers throw exception on server recycle before attempting reconnect

    Aspi Engineer Newbie

      JMS message producers throw an exception when JMS connectivity is lost but before the configured retries have been attempted. This seems to defeat the whole point of having the capability to automatically reconnect the JMS producer client. One would think that producers would first attempt to reconnect 'reconnect-attempts' times, and only if all attempts are exhausted would an exception be thrown. Throwing an exception before the retries have been attempted forces developers to wrap all javax.jms.MessageProducer#send() API calls inside of a try-catch block, and to reattempt the send atleast once more.

       


      This is the exception that is thrown by a producer client when the JMS server is recycled. The producer client eventually reconnects and is able to continue producing messages.

       

      Message:Connection failure detected. Unblocking a blocking call that will never get a response
      javax.jms.JMSException: Connection failure detected. Unblocking a blocking call that will never get a response
          at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:287)
          at org.hornetq.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:285)
          at org.hornetq.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:139)
          at org.hornetq.jms.client.HornetQMessageProducer.doSend(HornetQMessageProducer.java:451)
          at org.hornetq.jms.client.HornetQMessageProducer.send(HornetQMessageProducer.java:199)
          at com.putnam.jboss.topic.TopicSendLoop.send(TopicSendLoop.java:64)
          at com.putnam.jboss.topic.TopicSendLoop.run(TopicSendLoop.java:83)
          at com.putnam.jboss.topic.TopicSendLoop.main(TopicSendLoop.java:70)
      Caused by: HornetQException[errorCode=5 message=Connection failure detected. Unblocking a blocking call that will never get a response]
          ... 8 more

       

      Tested with 2.1.2Final.

       


      Thanks
      Aspi Engineer
      Putnam Investments

        • 1. Re: JMS producers throw exception on server recycle before attempting reconnect
          Hugh Bragg Newbie

          I thought configured retries applies to the consumer and was the number of retries Hornet attempted before it was sent to the DLQ.

          Retries for producer/consumer is applicartion dependent. No harm in creating a try/catch block and retrying as long as you don't loop forever.

          • 2. Re: JMS producers throw exception on server recycle before attempting reconnect
            Tim Fox Master

            Aspi Engineer wrote:

             

            JMS message producers throw an exception when JMS connectivity is lost but before the configured retries have been attempted. This seems to defeat the whole point of having the capability to automatically reconnect the JMS producer client. One would think that producers would first attempt to reconnect 'reconnect-attempts' times, and only if all attempts are exhausted would an exception be thrown. Throwing an exception before the retries have been attempted forces developers to wrap all javax.jms.MessageProducer#send() API calls inside of a try-catch block, and to reattempt the send atleast once more.

             


            This is the exception that is thrown by a producer client when the JMS server is recycled. The producer client eventually reconnects and is able to continue producing messages.

             

            Message:Connection failure detected. Unblocking a blocking call that will never get a response
            javax.jms.JMSException: Connection failure detected. Unblocking a blocking call that will never get a response
                at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:287)
                at org.hornetq.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:285)
                at org.hornetq.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:139)
                at org.hornetq.jms.client.HornetQMessageProducer.doSend(HornetQMessageProducer.java:451)
                at org.hornetq.jms.client.HornetQMessageProducer.send(HornetQMessageProducer.java:199)
                at com.putnam.jboss.topic.TopicSendLoop.send(TopicSendLoop.java:64)
                at com.putnam.jboss.topic.TopicSendLoop.run(TopicSendLoop.java:83)
                at com.putnam.jboss.topic.TopicSendLoop.main(TopicSendLoop.java:70)
            Caused by: HornetQException[errorCode=5 message=Connection failure detected. Unblocking a blocking call that will never get a response]
                ... 8 more

             

            Tested with 2.1.2Final.

             


            Thanks
            Aspi Engineer
            Putnam Investments

            This is explained in detail in the user manual

            • 3. Re: JMS producers throw exception on server recycle before attempting reconnect
              Tim Fox Master

              Hugh Bragg wrote:

               

              I thought configured retries applies to the consumer and was the number of retries Hornet attempted before it was sent to the DLQ.


              You're confusing redelivery attempts with connection reconnect attempts, they're quite different things.

              • 4. Re: JMS producers throw exception on server recycle before attempting reconnect
                Tim Fox Master

                Tim Fox wrote:

                 

                Aspi Engineer wrote:

                 

                JMS message producers throw an exception when JMS connectivity is lost but before the configured retries have been attempted. This seems to defeat the whole point of having the capability to automatically reconnect the JMS producer client. One would think that producers would first attempt to reconnect 'reconnect-attempts' times, and only if all attempts are exhausted would an exception be thrown. Throwing an exception before the retries have been attempted forces developers to wrap all javax.jms.MessageProducer#send() API calls inside of a try-catch block, and to reattempt the send atleast once more.

                 


                This is the exception that is thrown by a producer client when the JMS server is recycled. The producer client eventually reconnects and is able to continue producing messages.

                 

                Message:Connection failure detected. Unblocking a blocking call that will never get a response
                javax.jms.JMSException: Connection failure detected. Unblocking a blocking call that will never get a response
                    at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:287)
                    at org.hornetq.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:285)
                    at org.hornetq.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:139)
                    at org.hornetq.jms.client.HornetQMessageProducer.doSend(HornetQMessageProducer.java:451)
                    at org.hornetq.jms.client.HornetQMessageProducer.send(HornetQMessageProducer.java:199)
                    at com.putnam.jboss.topic.TopicSendLoop.send(TopicSendLoop.java:64)
                    at com.putnam.jboss.topic.TopicSendLoop.run(TopicSendLoop.java:83)
                    at com.putnam.jboss.topic.TopicSendLoop.main(TopicSendLoop.java:70)
                Caused by: HornetQException[errorCode=5 message=Connection failure detected. Unblocking a blocking call that will never get a response]
                    ... 8 more

                 

                Tested with 2.1.2Final.

                 


                Thanks
                Aspi Engineer
                Putnam Investments

                This is explained in detail in the user manual

                http://hornetq.sourceforge.net/docs/hornetq-2.1.2.Final/user-manual/en/html/client-reconnection.html

                http://hornetq.sourceforge.net/docs/hornetq-2.1.2.Final/user-manual/en/html/ha.html#ha.automatic.failover

                • 5. Re: JMS producers throw exception on server recycle before attempting reconnect
                  Alex Corvino Newbie

                  Sorry to resurect an old thread but we're seeing the same behavior in our failover tests. Killing a live server and failing over to a backup server will usually (but not always) give us a HornetQException in JMeter with the same errorCode=5 message=Connection failure detected. Unblocking a blocking call that will never get a response message and we'll see N less messages on our consumer with N being somewhere between zero and the number of failovers we did.

                   

                  Setting confirmation-window-size to anything other than -1 doesn't seem to do much for us beyond the occasional HornetQException with messages like this: errorCode=3 message=Timed out waiting for response when sending packet 71 and we've set the reconnect settings to try and reconnect every second with an unlimited number of reconnects. Is this just expected behavior in a failover scenario or did I configure something wrong? I've been reading over chapters 34 and 39 in the manual but I'm not seeing anything there that sugessts if I'm doing things correctly or not.