When commiting a large transaction while the system is under load, I received a timeout
javax.jms.JMSException: Timed out waiting for response when sending packet 43
Caused by: HornetQException[errorCode=3 message=Timed out waiting for response when sending packet 43]
... 9 more
This wouldn't be a problem I thought as it should send these messages again.
I was surprised when the messages were not sent again and had been removed from the queue.
I was under the impression that the commit wasn't permanant until the client had complete the hand shake with an ACK once the server acknowledged the commit batch.
Now these records are lost and cannot be recovered unless the client still has them and cannot be resequenced unless the client catches the timeout and distinguishes this JMSException from other JMSExceptions.
Could someone please advise on HornetQ implementation of the JMS standard concering commit timeouts. My reading was that the standard isn't explicit on this point, though I would have thought this to be crucial.
Specifically, what can be done to prevent this happening in the future?
Is there a way to guarentee delivery regardless of network problems assuming the network works correctly most of the time?