We have an app that does some very dynamic routing of hornetq messages so it reads from one queue and writes to another - within a single transacted session. The idea is that if we cannot move to the destination queue we won't remove it from the original queue. It works fine until we do some testing with network latency - things start to fall apart.
Because of the latency the transacted cannot be committed and cannot be rolled back.
We see a couple of thousands messages stuck in deliverycount and never clear out of there even after 20 minutes. We have the call timeout for the connection factory left at default - which is 30 seconds. The app has about 10 instances serving 8 different destination queues so you would think that if the delivering was being done sequentially we would not see more than 80 files stuck in deliveringcount but we do see way more than that.
These files get out of the deliveringCount only when the app shuts of or if we kill and restart sessions.
It seems that HornetQ is not able to timeout the transaction (you would think call timeout would do the trick maybe) and remove those files from deliveringcount.
Is there any property that we should look at?
I was looking for a transaction timeout but it comes only for XA transactions which we do not use.
By the way we use a messagelistener to receive the messages.
Here is the error we get on the rollback timeout (there is a similar timeout error on the commit as well) :
javax.jms.JMSException: HQ119014: Timed out waiting for response when sending packet 68
Caused by: HornetQException[errorType=CONNECTION_TIMEDOUT message=HQ119014: Timed out waiting for response when sending packet 68]
... 16 more