How does the LMAX Disruptor address typical message broker problems?

Question

My understanding of the LMAX Disruptor is that it is a JAR full of scary-fast, scary-concurrent Java code that allows a throughput of 20 million messages per second (if used correctly).

We currently have an ActiveMQ instance that is slow for what we need it to throughout, on the order of 400 messages per second. I'm wondering if we would benefit from refactoring our code to use LMAX, but have the following concerns:

• How to have 1 publisher and multiple (competing) consumers
• How does LMAX store/house its messages? In memory?
• Failover - does LMAX have failover protocols/mechanisms in place
• Disk I/O - can LMAX persist unconsumed messages to disk and recover them at a later time?

And, if I'm completely off base with all of these, and seem to be completely misunderstanding the use of LMAX Disruptors, then can someone provide a concrete example of when it would be used? Thanks in advance!

Answer 1

The Disruptor is not a direct replacement for a cross-process or cross-server messaging system. It is designed as an intra-process cross-thread messaging system. Think of it as useful to replace a graph of dependencies between processing threads that would normally have queues between them. This makes it useful for designs using pipelines or multicast patterns between threads. ActiveMQ serves a different purpose.

The threads within a Disruptor based systems are more like long lived Actors that communicate by passing events via the Disruptor.

For some good examples please look at the performance tests that are available with the source code.