[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-users
Subject:    Re: Acknowledgements and transacted sessions
From:       Gary Tully <gary.tully () gmail ! com>
Date:       2012-05-29 12:12:18
Message-ID: CAH+vQmMo4r92=hhgtbT5ZeHvs7S5wVEzmTWajaq-xwanq7nFbg () mail ! gmail ! com
[Download RAW message or body]

> I am unsure about this, hence the question.  If, all a transacted
> session would achieve, is to prevent the need for destroying the
> consumer then that would clear things up for me.
>
Yes, auto redelivery and dlq handling are the key differences between
the batch ack in a session.commit and an application initiated client
ack. (message.acknowledge)

On 29 May 2012 12:01, spam trap <nospam.1.friedbadger@spamgourmet.com> wrote:
> On Mon, 28 May 2012 15:42:21 +0100, Gary Tully
> <gary.tully@gmail.com> wrote:
>
>>there are two aspects to this:
>>1) standard jms redelivery semantics. In activemq this is handled  by
>>the consumer, so client side.
>>redelivery occurs on "transacted" sessions if there is a rollback or
>>an exception processing the message.
>>While redelivery is in process, the message is not visible to any
>>other consumer. From the brokers perspective
>>it is considered 'inflight'. If redelivery fails (too many retries),
>>the consumer uses a poison ack to indicate to
>>the broker that the message should go to the dead letter q (dlq) if
>>one is configured.
>>It does not sound like that is what you want.
>
> No.  Messages must eventually be consumed and we don't want anything
> ending up on a DLQ.
>
> However the same message *must not* be delivered to more than one
> consumer.
>
>>2) the behavior when a consumer is closed with inflight messages. the
>>broker will dispatch to another consumer.
>>Prefetch is relevant here, set it to 0 if you don't want any unacked
>>messages to build up on the consumer.
>>
>>With client ack, note that it is inclusive - so ack all messages
>>received so far, you would need to use the extension,
>> INDVIDUAL_ACK_MODE to only ack successful messages (if you have prefetch > 1)
>>
>>The simplest approach is to close the consumer on error so that the
>>broker gets an immediate chance to redeliver to another consumer.
>
> That sounds good.  It is antcipated that an error would be rare enough
> not to worry about the overhead of creation.
>
>>If the overhead of consumer creation is too much, then look at jms
>>redelivery semantics and a transacted session.
>
> I am unsure about this, hence the question.  If, all a transacted
> session would achieve, is to prevent the need for destroying the
> consumer then that would clear things up for me.
>



-- 
http://fusesource.com
http://blog.garytully.com
[prev in list] [next in list] [prev in thread] [next in thread]