I've a question regarding the HornetQ 2.1.2 paging:
I did some performance tests with a simple JMS client today. The client is just having a producer and a consumer thread. The producer thread simply constantly produces 1Kb ByteMessages in a transacted session into a queue; each message gets committed separately. The consumer simply consumes all produced messages in another transacted session, each message gets committed separately as well; it is started later than the producer to enforce paging. Code is attached.
The address of the used queue is configured like this:
Now, the producer runs, the queue gets filled up and finally paging starts at ~ 13000 messages in the queue. So far so good. As soon as the consumer kicks in, the queue length decreases, the message count shown via JMX jumps a bit up and down as soon the messages get depaged and finally ends up around 0. The new paging files written to disk get smaller and smaller before they get processed and deleted. However, more than 10000 files are being written in a row, most of them about 2Kb big. Paging doesn't stop for *minutes* after the queue is reported as more or less empty. HornetQ still pages each message out to disk just to depage it more or less immediately. This impacts performance heavily. Paging only gets switched off if the sender gets stopped for some seconds or if the queue probably gets empty for a short time due to some other event. The log (with enabled trace logs for org.hornetq.core.paging.impl.PagingStoreImpl) is attached. The paging and depaging seems to be a bit disconnected here, paging could stop much earlier in my point of view.
Is this issue somehow addressed in the new HornetQ 2.2 paging?