AMQ is sensitive to proper memory configuration. Typically what will happen is the memory configuration in the activemq.xml doesn't line up with the JVM heap and this causes garbage collection thrashing. It reaches a point where the CPU spikes and the monitor process zaps the JVM process, which causes a restart.
If everything is tuned and lined up properly this won't happen. I've used AMQ in high-volume production systems for years without this problem.
This is a test of the default configurations of various brokers, NOT the brokers themselves.
Apart from declaring the testing queues in some brokers’ configuration and the persistence settings, all brokers were running with their default configuration out of the box (no tuning made).
He also casually mentions that ZeroMQ is using an in-memory configuration.
A home-made ZeroMQ 2.2.0 broker, working in memory only (no persistence).
The default configuration of AMQ persists messages to journal on disk. So apples to oranges?
Why do people keep writing "benchmark" blog posts like this?
If everything is tuned and lined up properly this won't happen. I've used AMQ in high-volume production systems for years without this problem.