activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From spam trap <>
Subject Re: Acknowledgements and transacted sessions
Date Tue, 29 May 2012 11:01:02 GMT
On Mon, 28 May 2012 15:42:21 +0100, Gary Tully
<> 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

>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.

View raw message