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.