We have a clustered setup (3 master/3 backup nodes) with a shared storage. I wonder why messages are lost when a failover is done (shutting down one master node, after failover has occured the master node is restarted again and becomes the live instance).
We are using plain JMS for producing and consuming:
session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
QueueSession session = connection.createQueueSession(true, Session.AUTO_ACKNOWLEDGE);
message = queueReceiver.receive(2000L);
During the failiover the client gets several exceptions:
STDERR 'Caused by: HornetQException[errorCode=3 message=Timed out waiting for response when sending packet 49]'
ERROR 2013-06-13 17:23:22,078 [http-0.0.0.0-6003-37][d0a99a0f-0d09-4f9d-99d0-5de4336f409c] STDERR ' at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:302)'
ERROR 2013-06-13 17:23:22,078 [http-0.0.0.0-6003-37][d0a99a0f-0d09-4f9d-99d0-5de4336f409c] STDERR ' at org.hornetq.core.client.impl.ClientSessionImpl.bindingQuery(ClientSessionImpl.java:399)'
"Unblocking a blocking call that will never get a response"
According to the docs:
"If the client code is in a blocking call to the server, waiting for a response to continue its execution, when failover occurs, the new session will not have any knowledge of the call that was in progress. This call might otherwise hang for ever, waiting for a response that will never come.
To prevent this, HornetQ will unblock any blocking calls that were in progress at the time of failover by making them throw a
javax.jms.JMSException (if using JMS), or a
HornetQException with error code
HornetQException.UNBLOCKED. It is up to the client code to catch this exception and retry any operations if desired."
What is the recommended way here? Is it safe to retry in case of HornetQException.UNBLOCKED and/or HornetQException.CONNECTION_TIMEDOUT? Are there any recommendations regarding the consumer? In which exception cases must transactions be rolled back/when is HornetQ rolling back itself?