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: domain of gary.tully@gmail.com
 designates 209.85.213.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <DC3AE23C-F7ED-4D7E-90C4-24F97B9E6F9E@yahoo.com>
References: 
 <CAFAd71Va_WY1_BSFKFRfC3wkv+qyXpmq4maPUB=oMwGUBm8PvQ@mail.gmail.com>
	<CA+KXqX=9G7ybAFHVL6LSXizTEJqpdpYsO4gpxXHXU-p7dcJ0OA@mail.gmail.com>
	<CA+KXqX=10t+o2m74V8Kc5huWAgXmvEDO281qLLvb9iLxh7x-3A@mail.gmail.com>
	<1393294230808-4678338.post@n4.nabble.com>
	<CAFAd71XbZc_xJ9xv-hz-eOdr_pjAGaYWi-4+X=E3vGvfJAj3xA@mail.gmail.com>
	<DC3AE23C-F7ED-4D7E-90C4-24F97B9E6F9E@yahoo.com>
Date: Tue, 25 Feb 2014 11:41:38 +0000
Message-ID: 
 <CAH+vQmM=_o5AMpBozvgV9o2EK+3NdqBKZ1aGtv+N_SqY+Vw76g@mail.gmail.com>
Subject: Re: does AUTO_ACKNOWLEDGE guarantee once and only once semantic for
 queue consumer?
From: Gary Tully <gary.tully@gmail.com>
To: "users@activemq.apache.org" <users@activemq.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

in the absense of xa, I think we can do better with the redeliveryflag
such that it can be used as a reliable indication of duplicate
dispatch. In that way, an application can avoid doing duplicate checks
when the flag is not set, even after a broker failure.

It will come as a cost, but it opens up a new class of usecases.
see: https://issues.apache.org/jira/browse/AMQ-5068

On 25 February 2014 02:54, David Jencks <david_jencks@yahoo.com> wrote:
> Using activemq with a jta transaction manager and using the appropriate xa interfaces (such as through the resource adapter) will guarantee that a message is delivered exactly once.  Many people prefer to use idempotent messages to avoid the xa overhead.
>
> david jencks
>
>
> On Feb 24, 2014, at 6:45 PM, Li Li <fancyerii@gmail.com> wrote:
>
>> thanks. Since JMS can't guarantee only once, it's the client's
>> responsibility to make things correct. it should either using
>> idempotent processing(running a task twice is no harm) or using other
>> tools(such as zookeeper or database to make data consistent). So I
>> think there is still many dirty work to do in some strict environment.
>> is there any practical usage of JMS(activemq) in real world in
>> industry such as financial or e-commerce?
>> on the other hand, does JMS guarantee at least once delivery? What's
>> the redelevery mean?
>> as said in https://activemq.apache.org/message-redelivery-and-dlq-handling.html
>>
>> Messages are redelivered to a client when any of the following occurs:
>>
>> A transacted session is used and rollback() is called.
>> A transacted session is closed before commit is called.
>> A session is using CLIENT_ACKNOWLEDGE and Session.recover() is called.
>>
>> I notice that when a client crashed in the onMessage method and
>> restart. the message will be dispatched to another consumer with
>> getJMSRedelivered()==true. it this message a redelivered one?
>> also, if the consumer is very slow(maybe hang for an hour,stay in
>> onMessage so it's not acknowledged) and the message has a short TTL,
>> will it be redelivered to another consumer or to dead letter queue?
>>
>>
>> On Tue, Feb 25, 2014 at 10:10 AM, artnaseef <art@artnaseef.com> wrote:
>>> The use-case sounds like one that needs more than just ActiveMQ to solve
>>> well.
>>>
>>> In JMS, redeliveries of messages must be expected and handled by
>>> applications.  There are cases where the JMS redelivered property is set,
>>> but the application may not have touched the message ever before - such as
>>> when the message is dispatched in the prefetch for the client and the client
>>> terminates without getting to the message.  Even with prefetch 0, the same
>>> problem can happen.
>>>
>>> The JMS redelivered property is a hint that lets an application know that
>>> there is a risk the message was actually handled before.
>>>
>>> My preference is to think of JMS guarantees as a great way to simplify the
>>> normal processing path in an application as it eliminates the need to
>>> consider how messages can get lost in transit and protecting against the
>>> same.  However, it's not intended to be a way to signal to the broker to try
>>> a different consumer.  And it doesn't eliminate considerations under error
>>> cases - such as a consumer terminating in the middle of processing the
>>> message.
>>>
>>> On the practical front, rejecting a message so that the broker resends it
>>> will introduce notable delay.  It may also result in the message being
>>> redelivered to the same client.  Also, I would need to check -- there may
>>> also be a TTL issue in which case the message could end up stuck on the
>>> broker.
>>>
>>> In your use-case, I would consider ActiveMQ as an underlying component to a
>>> complete solution.  Perhaps using camel with a server that routes tasks to
>>> task engines.  Also, I recommend considering a proactive approach to the
>>> problem.  Waiting until the task reaches a task engine to have it rejected
>>> may lead to problems.  For example, what if the fastest task engine is too
>>> slow for the task?  The task will starve.  Using feedback from the task
>>> engines to the routing engine, the routing engine can decide the best task
>>> engine using heuristics (such as best fit - not always the fastest engine).
>>>
>>> To get the guarantee a task only ever executes once, you'll need a reliable
>>> lock/state engine.  Zookeeper comes to mind.  Note that many applications
>>> prefer to use an idempotent processing model so that duplicate processing
>>> causes no problems.
>>>
>>> Hope this helps.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://activemq.2283324.n4.nabble.com/does-AUTO-ACKNOWLEDGE-guarantee-once-and-only-once-semantic-for-queue-consumer-tp4678300p4678338.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>


-- 
http://redhat.com
http://blog.garytully.com