Does ActiveMQ guarantee message delivery?

Question

When we using ActiveMQ how much we can trust reliability of ActiveMQ Server. For example while developing non real time software(no need to send data instantly. But it should be send). Can we trust activeMQ as reliable source that confirm message delivery. For example i'm sending a xml file from producer. send that file to ActiveMQ confirmed ActiveMQ delivery. Then can i trust ActiveMQ and delete local copy of xml?

EDITS

When a message reached the ActiveMQ server it's reliable. How can we make sure reliability of producer Server link. In case producer is a java SE application. how ActiveMQ client handles these scenarios

• forced shutdown of application while preparing data to send.
• network failure while sending message.

Answer 1

If you send to ActiveMQ using transaction and persistent delivery (pretty much default if you go by JMS) and the transaction commit successfully - yes. Then ActiveMQ have secured the message on persistent storage (usually disk).

Then, of course, a disk can crash and human mistakes and earth quakes can hit you , but otherwise, the message is ok.

Answer 2

ActiveMQ is bound to the JMS specification, which mandates that a JMS provider must, by default, guarantee delivery of 'persistent' messages. This guarantee does come with a heavy performance price because the broker must securely persist the message in its message store prior to acknowledging the message to the producer. A local JMS transaction is not required for this guarantee, but can be used to batch messages to the broker, which is one way of overcoming the heavy performance price.

Answer 3

I would suggest that the Producer can't discard the XML message until the Client has confirmed that it has received the message. It is not sufficient to just confirm it has been received by the ActiveMQ server, as the message has no value until the Client has received it.

So to that end, I would find some kind of a confirmation of receiving to be a good approach. A simplified system might work something like this...

Initial Setup

First, create two topics: 'messages', and 'message-receipts'.

Next, set up the Producer to publish to the 'messages' topic, and subscribe to the 'message-receipts' topic. The Producer should also be able to maintain a list of all messages sent, but not yet confirmed.

Additionally, your Client will subscribe to the 'messages' topic, and publish to the 'message-receipts' topic.

Publishing Messages

To publish a message, the Producer will first generate an XML message, and give it a unique ID that can identify the message. It then will publish it on the 'messages' topic.

The Client then, will see the message on the 'messages' topic. It must then turn around and publish a 'message-receipts' response, which will contain the ID of the message received.

Finally, the Producer will see the 'message-receipts' message, and can confirm a message has been sent by comparing the message-receipt ID with the list of as yet to be confirmed messages. Once confirmed, the message is removed from the "sent but not yet verified" list.

Handling Non-Received Messages

The Producer can resend a message if no receipt has occurred for some period of time.

Answer 4

Yes, ActiveMQ is a message broker based on JMS, which at its core, is designed to guarantee reliable delivery of messages. To understand this better, let us consider the message path through the system, i.e. from production to consumption.

The message is usually delivered in two hops. The first hop is where the message is transmitted from the producer to a destination on the message broker, in this case, ActiveMQ. In the second hop, the message is transmitted from a physical destination on the broker to the consumer.

During this process, there are only three ways through which a message can get lost in its path. The first is as it moves from the producer to the message broker. The second possible loss-point is in the broker memory, and lastly, on its path from the broker to the consumer.

ActiveMQ uses two mechanisms to ensure messages are not lost in any of the three ways. The first is that the broker stores all messages in a highly persistent data store. If the system is interrupted or the broker memory fails before the message is successfully delivered, the broker can still retrieve the message upon recovery and retry the operation.

Secondly, ActiveMQ uses acknowledgments and transactions to ensure that both production and consumption of messages is successful. Even with these two approaches, there can be situations when a message is not delivered successfully. For instance, when the transacted session for consuming the messages is rolled back. When this occurs, the message is returned to the queue and redelivered.

ActiveMQ provides two ways to deal with messages that are returned to the queue and redelivered without success. These are delayed redelivery and dead letter address.

For delayed redelivery, messages are delayed for a while to allow the consumer to recover from transient failures and prevent network or system overload. Here’s an example showing how you can define delayed redelivery in the address-setting configuration.

<!-- delay message redelivery for 5 seconds -->
<address-setting match="exampleQueue">
   <!-- default is 1.0 -->
   <redelivery-delay-multiplier>1.5</redelivery-delay-multiplier>
   <!-- default is 0 (no delay) -->
   <redelivery-delay>5000</redelivery-delay>
   <!-- default is 0.0) -->
   <redelivery-collision-avoidance-factor>0.15</redelivery-collision-avoidance-factor>
   <!-- default is redelivery-delay * 10 -->
   <max-redelivery-delay>50000</max-redelivery-delay>
</address-setting>

For dead letter address, messages in the unsuccessful deliveries are removed from the queue and sent to a dead letter address. The broker does not attempt to redeliver such messages but places them in a queue where the system administrator can access and take action.

Below is a simple configuration of a dead letter address.

<!-- undelivered messages in the Queue are sent to a dead letter address
after 3 unsuccessful redelivery attempts -->
<address-setting match="exampleQueue">
   <dead-letter-address>deadLetterAddress</dead-letter-address>
   <max-delivery-attempts>3</max-delivery-attempts>
</address-setting>