I was told a while back about the LMAX disruptor and how performant it is compared with standard message queues. I downloaded the latest version and see that it’s an ordinary JAR that contains lots of classes and types that all revolve around its ultra-fast RingerBuffer object.
Ultimately speaking, at the end of the day, a queue-based JMS provider is just going to boil down to a lot of code managing a Java queue object (or, more likely a concurrent queue). So in this respect, I see the comparison between the LMAX Disruptor and a JMS provider (or rather, it’s internal queue).
But a JMS provider is so much more than a few queues. It’s an entire middleware application for handling messaging to/from consumers and producers. I’m wondering if there is a JMS provider equivalent in LMAX land?
It would be nice to connect to a “Disruptor Broker” in a similar manner as any other JMS broker, and read/write messages to/from it.
Does anything like this exist, or am I way off-base here?
The main difference is that the Disruptor is designed to work in the same process. Why? For performance reasons (the short answer). The longer answer is that if you are not careful the extra overhead of using JMS interfaces, socket connections, locking and multiple threads will have far higher overhead which dwarfs the Disruptor.
A fast JMS service can handle over 20,000 messages per second, but the disruptor is design to handle message rates of 20 million per more. To achieve this it means you can’t do certain things which JMS assumes is ok. (see above)