Question

I'm working for a company where we're considering Mule ESB. We would need to set up Mule in a clustered configuration to get what Mule coins a Mule High Availability (HA) Cluster.

Now, we need to persist incoming messages to a queue in case of power outage or disk failure. As far as I understand, we can either go with the default Mule Object Store which "persists" messages to a shared memory grid. However, my first thought here is that this can't be any good if we get a power outage which takes the entire cluster out of action.

Our other option is to use a separate queue product such as RabbitMQ or ActiveMQ. However, do these integrate alright with a HA cluster? Are there any mechanism in these products which ensures that the same message won't be picked up by two machines at the same time?

Consider this scenario (based on the observer pattern):

  1. Mule receives a message, puts it on a queue and responds with an OK to the client which delivered the message.
  2. Mule picks up a message from the queue, and attempts to deliver it to a subscriber.
  3. The subscriber accepts the message, and Mule removes it from the queue.

What happens if another Mule instance in the HA cluster attempts to pick up the message between 2 and 3 above? Is there a mechanism where Mule can indicate that a message is picked up from the queue to be "attempted delivered" but then, if the delivery fails, update the message on the queue as "not delivered" if delivery fails?

Was it helpful?

Solution

Both RabbitMQ and ActiveMQ will give you the once-and-only-once functionality I think you are looking for.

Both platforms ensure that each message in a queue is received by only one subscriber.

In ActiveMQ, to return a message to a queue in the event of a failure, you can use explicit message acknowledgement or JMS transactions. Here's a quick overview.

In RabbitMQ, you do it using acknowledgements.

Also, you might want to consider reliability for your message broker. Both ActiveMQ and RabbitMQ offer highly available broker configuration options.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top