-
1. Re: JMS producers throw exception on server recycle before attempting reconnect
hughbragg Sep 13, 2010 11:58 PM (in response to aengineer)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
timfox Sep 14, 2010 2:57 AM (in response to aengineer)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 moreTested with 2.1.2Final.
Thanks
Aspi Engineer
Putnam InvestmentsThis is explained in detail in the user manual
-
3. Re: JMS producers throw exception on server recycle before attempting reconnect
timfox Sep 14, 2010 2:59 AM (in response to hughbragg)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
timfox Sep 14, 2010 3:54 AM (in response to timfox)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 moreTested with 2.1.2Final.
Thanks
Aspi Engineer
Putnam InvestmentsThis 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
-
5. Re: JMS producers throw exception on server recycle before attempting reconnect
alexc099 Dec 9, 2011 2:31 PM (in response to aengineer)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.
-
hornetq-jms.xml 994 bytes
-