2

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!

IAmYourFaja
  • 55,468
  • 181
  • 466
  • 756

1 Answers1

8

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.

Martin Thompson
  • 1,341
  • 8
  • 11
  • Thanks @Martin Thompson (+1). So is the idea to have each thread act like its own Enterprise Integration Pattern (EIP), and Disruptor is the ultra fast messaging system between each EIP thread? –  Mar 30 '13 at 15:16
  • 1
    The Disruptor is useful for putting in front of IO to network or disk so that smart batching can be applied and therefore amortise the cost of expensive IO operations in a lock-free manner. I'm not a fan of most "enterprise" software because of the cost it can add for little value. Individual threads can handle IO but they can also be performing business logic. Mike and I talked about this at QCon a few years back. http://www.infoq.com/presentations/LMAX – Martin Thompson Mar 31 '13 at 12:50