Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=l/6OyObG0CUpMvfeK53pW2uSI/XEzdlZs1S9VH+sqAsKbCzPvPTXkTnhVGRjbt3jjv72LOZBvhg368dgtAv/35Jbz10mLgu9/xAweGuxeb6KuO1QNdWjHTILash0t2fMDnF912oq4S9cqJyBJnA5WfaQ3t3KFOmMhiILizx6jZs=
  ;
Message-Id: <E90995BF-D84D-4246-B82A-F0D5C94DD322@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: users@activemq.apache.org
In-Reply-To: <7F472EB9-AC7E-46CD-A24C-3DD13BE6AC9F@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Reconciliation after ActiveMQ server crash.
Date: Fri, 28 Nov 2008 10:03:36 -0800
References: <20734165.post@talk.nabble.com>
 <7F472EB9-AC7E-46CD-A24C-3DD13BE6AC9F@gmail.com>

I looked at the failover docs I could find and I think thabach was  
asking a different question that AFAICT the failover docs don't  
discuss... anyway I've wondered about this question :-) :

Suppose a client sends a message inside a transaction and either the  
client or broker crashes before the tx.commit() call has returned.   
How can the client determine if the transaction completed, so the  
message will be delivered eventually, or failed, so the message needs  
to be re-sent?

I recall reading the the big Transaction Processing book that in the  
distant past terminals were considered transactional resources so that  
unless the user actually saw that the transaction had comitted  
successfully, it was not committed: either rolled back or left in the  
"prepared" state.

The only way I know of to actually guarantee this is to send the  
message inside an xa transaction where the sending of the message is  
recorded "locally" somehow, for instance by marking the data that the  
message is generated from or by inserting a record into a database.

I would guess that it would often be easier to write message receiving  
code that can handle duplicate messages.

There may be other ways to deal with this...

thanks
david jencks

On Nov 28, 2008, at 8:21 AM, Rob Davies wrote:

> This is handled by the ActiveMQ failover transport (the default in  
> 5.1 onwards).
> It replays messages on your behalf that haven't been acknowledged -  
> there is duplicate detection built in to the broker and the clients  
> too ...
>
> cheers,
>
> Rob
>
> cheers,
>
> Rob
>
> Rob Davies
> http://fusesource.com
> http://rajdavies.blogspot.com/
>
>
> On 28 Nov 2008, at 13:09, thabach wrote:
>
>>
>> Hey everyone
>>
>> I have a conceptual question regarding reconciliation after a JMS  
>> server
>> crash. According to the JMS specification (paragraph 4.4.13, see  
>> below)
>> there is room for some ambiguity leaving a producer in doubt if a  
>> message
>> successfully made it to the server or not in case of server failure.
>>
>> The [X] part is what disquiets me: "It is up to a JMS application  
>> to deal
>> with this ambiguity."
>>
>> A producer in doubt can only resend the original message. In what  
>> way does
>> ActiveMQ support me in doing so ? Are there any means of having  
>> ActiveMQ
>> sort out potential duplicates sent by the application layers after  
>> server
>> recovery and publisher reconnect ? Or do downstream consumers have  
>> to cope
>> with these kind of duplicate messages somehow ?
>>
>> Regards and thanks for any insights, Christian.
>>
>>
>> == JMS spec excerpt ============================================
>>
>> 4.4.13 Duplicate Production of Messages
>> JMS providers must never produce duplicate messages. This means  
>> that a
>> client that produces a message can rely on its JMS provider to  
>> insure that
>> consumers of the message will receive it only once. No client error  
>> can
>> cause a
>> provider to duplicate a message.
>>
>> If a failure occurs between the time a client commits its work on a  
>> Session
>> and
>> the commit method returns, the client cannot determine if the  
>> transaction
>> was
>> committed or rolled back. The same ambiguity exists when a failure  
>> occurs
>> between the non-transactional send of a PERSISTENT message and the  
>> return
>> from the sending method.
>>
>> [X] It is up to a JMS application to deal with this ambiguity. In  
>> some
>> cases, this
>> may cause a client to produce functionally duplicate messages.
>> A message that is redelivered due to session recovery is not  
>> considered a
>> duplicate message.
>>
>> ======================================================
>>
>> -- 
>> View this message in context: http://www.nabble.com/Reconciliation-after-ActiveMQ-server-crash.-tp20734165p20734165.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>