4

Is the disruptor actually a replacement for application instead of JMS? I currently transfer tasks using JMS messages.

Is the disruptor intended to replace it for message transfer? what are the pros/cons of each one?

Currently I use JMS, I have a producer that sends messages to a queue and consumers (MDBs) that pull them off the queue.

Thanks.

Emmanuel Bourg
  • 9,601
  • 3
  • 48
  • 76
cchaoss
  • 41
  • 4

2 Answers2

6

No, Disruptor is not a replacement of JMS. Disruptor is based on ring buffer data structure that is similar to a queue model, but with difference in the way elements are treated and tracked. It can be used similar to Queues but there are fundamental differences. For instance the consumer will have to track from where an element was consumed as opposed to FIFO (or concurrent) delivery model in a queue. Here is a stackoverflow discussion that gives you further detail

Community
  • 1
  • 1
ring bearer
  • 20,383
  • 7
  • 59
  • 72
1

If we are talking about application scope, then yes, I agree with the topic author: disruptor came to replace JMS. In many organizations (including mine past) people used JMS to create their own internal frameworks to decouple application modules using JMS inside and make it async.

But what disruptor does not do: it does not replace JMS in terms of communication between applications.

I would recommend to use disruptor instead of JMS inside apps, it's easier to use, more understandable, more powerful etc.

Denys
  • 1,308
  • 12
  • 13