FWIW, I've nailed down my problem, it was a heavy I/O process running on the host node, sucking out all the I/O from the broker that was running in a (somewhat misconfigured) VM.
That being said, is it possible to have a "diskless" broker and still have persistence? All my messages are persistent, but I'm not sure if they really need to be. I've made them persistent only because they are all going to durable topics, but docs are really moot about this, and I can't remember if I tested if non-persistent messages can be sent to durable topics. Reynald Borer <reynald.bo...@gmail.com> writes: > Hi guys, > > > Have you tried to enable GC logs to see if maybe a full GC is > happening while everything is slowed down? > > > In the past I encountered the same issue where for an unknown reason > the GC activity was suddenly high, making a full GC of 0.2 seconds > every second. I spotted this issue because the GC logs where active > (and of course also because everything seemed to be slowed down). > > > This happened with the amq persistence adapter and not kahaDB (using > version 5.3.0). And now the problem is solved simply because the > number of connection has been lowered, which is not an ideal > solution. So I'm really interested if you find something useful. > > > Regards, Reynald > > > On Monday, December 13, 2010 at 15:58 , > robert.sl...@misys.com wrote: > >> I have tried each of the different cursor types with 5.4.1, but >> since downloading the 5.4.2 version, I have not changed the cursor >> used, so this is the default configuration, where no cursor is >> defined for queues - this should result in the default store cursor >> being used. >> >> I have just tried with enableJournalDiskSyncs = "false", but this >> results in similar slow processing after a batch of messages have >> been processed. Although with this approach the consumer thread >> seemed to be more hindered than the producer, as messages were being >> produced onto the test queue around 3-4 times faster than they were >> being consumed. Once again I get the same EOFException thrown and >> message production/consumption seems to slow periodically, for >> greater periods the more messages I process. -- View this message >> in context: >> http://activemq.2283324.n4.nabble.com/Slow-throughput-after-several-hundred-messages-tp3082431p3085521.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> >> >> >> > >