How are you sending your messages? Persistent, non persistent?
Maybe you should increase the call-timeout depending on the way you're sending the message. (Like, persistent, non transactioned. As you will have the system waiting the persistency at the server).
It is likely this is what's happening. Probably you are sending faster than what your disk would be able to sync. Maybe you could send more than one message per transaction.
Currently I'm posting with JMS to a Topic non durable.
In Regards to:
"Maybe you should increase the call-timeout depending on the way you're sending the message. (Like, persistent, non transactioned. As you will have the system waiting the persistency at the server)."
I'd rather having it fail fast, line in two seconds instead of waiting longer, as I'm not interested in getting the message sent if it's old.
that doesn't answer the question...
I'm asking what kind of session you are using. Transactioned? Persistent Message?
If you are only using non-durable subscriptions, you probably should set your producer to durable=false
That will disable syncing on the waiting of the sends (packet=71 is message send)
I'm sending with AUTO_ACK, and I'm not setting persistence explicitly so it will by default be sent as persistent.
I will change that and see if the problem persists.
Though, if I would like to send it persistent, and I'm producing less than a 40 messages per second, I don't think it's reasonable to wait 30 seconds for the persistence layer to sync.
I don't think that's happening.. I just don't have any information.
Are you paging by chance? If that's true maybe you could give a try on 2.2.5? (why don't you give a try anyway?)
The chances you are using paging is pretty high in your case. You have several topics and several subscriptions. You should definitely try the latest version. (2.2.5)
You can just replace the jars from the installation. (no need to replace the whole thing if you don't want to).
Thanks for your comments so far.
In regards to paging on hornetq level, we're monitoring that closely and in very few cases we've seen paging occuring.
For OS level paging, we're having a few Gb of free memory on top of the max heap allocated for HornetQ.
For 2.2.5, would I need to replace jars on both client and server sides?