[rabbitmq-discuss] Exactly Once Delivery

[Tim Fox]

On 05/08/10 15:16, David Wragg wrote:
> Tony Garnock-Jones<tonyg at rabbitmq.com>  writes:
>    
>> John Apps wrote:
>>      
>>> The JMS standard offers guaranteed once
>>>        
>> What exactly do they mean by that? In particular, how do they deal
>> with duplicates? Do they report failure, or silently let a dup through
>> in certain situations? If you could point me to the part of the spec
>> that sets out the JMS resolution of these issues, that's be really
>> useful.
>>      
> As an API spec, it's quite easy for JMS to mandate something apparently
> impossible, without hinting at how it might actually be implemented.
>
> Most of the spec says that the PERSISTENT delivery mode gives
> "once-and-only-once" delivery.  But section 4.4.13 (of JMS 1.1) admits
> that there are a number of caveats to this.  So it's really
> "once-and-only-once-except-in-some-corner-cases".
>
> I think the wrinkle that might prevent us saying that RabbitMQ gives the
> same guarantees is on the publishing side.  The caveats in JMS all seems
> to apply only to the consuming side.  But what happens with an AMQP
> producer if the connection gets dropped before a tx.commit-ok gets back
> to the client?  In that case the client has to re-publish, leading to a
> potential dup.  This can be avoided by a de-dup filter on published
> messages in the broker.  I don't know if JMS brokers really go to such
> lengths.
>    
Some do. It's fairly common for JMS brokers to implement duplicate 
detection on the server side, to get around the "lost commit-ok problem" 
and give us near as possible once and only once, from the publisher to 
the server at least.

The way we do it in HornetQ is we have a well defined header key 
"_HQ_DUP_ID". The client can set this with some unique value of it's 
choice before sending (e.g. a GUID). When the server receives the 
message if the _HQ_DUP_ID header is set, it looks up the value in it's 
cache, and if it's seen it before it ignores it. The cache can 
optionally be persisted.

On the client side, the producer can resend the message/transaction if 
it does not receive a confirmation-ok, so it effectively makes 
sends/commits idempotent.
David
>    


-- 
Sent from my BBC Micro Model B

Tim Fox
JBoss

HornetQ - putting the buzz in messaging http://hornetq.org
http://hornetq.blogspot.com/
http://twitter.com/hornetq
irc://irc.freenode.net:6667#hornetq	
fox at redhat.com