LMAX Disruptor vs JMS Provider

Question

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?

Answer 1

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)

Answer 2

It was a time when organizations developed their own frameworks for the internal use (CRUD, ORM, etc). One of the framework I had a chance to work with was an internal message buffer (mediator) that ensure asynchronous decoupling between application parts like messages consumer and more slow (intermittently) processing/persisting/networking part. That mediator was build based of ActiveMQ that was launched with the app and used for the dedicated app instance only.

Nowadays, we have a ring buffer framework Disruptor (or Reactor that is built on it) available and there is no reason to invent the wheel again (thanks to open source). The purpose of Disruptor is to bring the asynchronous decoupling with a FIFO buffer and make it much faster and convenient to use.

Advantages of Disruptor over JMS:

1. How it was mentioned above it's the same process and it's much faster.
2. No need to support, maintenance and pay for external middleware component.
3. It's inside the app, no need to involve any TCP connections, networking or other crap external slow bottleneck resources and be dependent on it and their teams.
4. Disruptor has so many features like parallel consumption and processing (workers vs handlers) strategies with implementations out of the box or you can implement your own strategy as per you behavior requirements.

Disruptor wiki