[rabbitmq-discuss] Exactly Once Delivery
mike.petrusis at ericsson.com
Fri Aug 6 03:28:17 BST 2010
Thanks all for the input. I've got a better understanding of the issues now and it sounds like the issue is the same regardless of the use of transactions.
Matthew's idea of having producers add a "republish count" to the messages is good suggestion to optimize the de-duplication of messages, but this only helps for messages resent by a producer.
Can messages get duplicated while they are propagating in the broker? If duplicates are produced in the broker they will have the same "republish count" and this method won't work.
From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Matthew Sackman
Sent: Thursday, August 05, 2010 9:26 AM
To: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Exactly Once Delivery
On Thu, Aug 05, 2010 at 09:16:14AM -0700, Tony Menges wrote:
> The JMS provider sets the message id. It is supposed to be unique enough to be used for a "historical repository" but the scope of uniqueness is left to the provider. It is recommended that it should be at least unique for a given "installation". I don't think this helps on the publisher side since as you pointed out the notification of the completion of the publish might not make it back to the producer.
> JMS requires the provider to set the redelivered flag (and optionally the delivery count) field if it thinks the message has been given to the application before. The application may or may not have seen it but this flag can be used to trigger the check for a duplicate by the application. The use of unique message ids helps on this end.
Ahh interesting. It would thus seem that JMS requires slightly more of
the producer when publishing messages (more logic is required in the
client library there) and AMQP possibly requires more at the consumer
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss