Look in db/jbossmq/file. Do a lot of fast subsequent ls -la's and you'll see a bunch of small files being created and destroyed.
I solved it with a ramdisk. Alternative is rollinglogged PersistenceManager, but it kills performance by about 300 messages/second.
Strange things also happen when you actually want persistence...
Actually i don't see that, not in db/jbossmq/file or db/jbossmq/file/QUEUE.myQueue. Do you know what is being written and by which class?
Most importantly, can it be turned off? Either through configs or extending a class (or editting a class) and rebuilding jboss?
Why would this disk io be necessary?
you may want to check if the in memory queue is being written to disk. This is governed by
looks like 1 message per file once the vm is the size specifiec by messageCache.
The message cache writes to tmp/jbossmq I think...
In my tests the Cache values were set in the region of 1.5Gb
and I never came close to reach that so I suspect it is the Persistence Manager.
I'm toying with the idea of writing my own PM that does nothing, but that is a bit of a low priority idea at the moment.