You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by spam trap <no...@spamgourmet.com> on 2012/05/28 12:00:46 UTC
Acknowledgements and transacted sessions
Hi,
Can someone help me understand better the way ActiveMQ handles
transactions and acknowledgements?
I need to write a consumer that processes a message. If something
goes wrong or the consumer crashes we need the message to be consumed
again (when the consumer is restarted).
Should I use CLIENT_ACKNOWLEDGE (with message.acknowledge()) or
SESSION_TRANSACTED (with a session.commit())?
Re: Acknowledgements and transacted sessions
Posted by johnbing <bi...@gmail.com>.
Please respond...
--
View this message in context: http://activemq.2283324.n4.nabble.com/Acknowledgements-and-transacted-sessions-tp4652740p4675021.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Acknowledgements and transacted sessions
Posted by johnbing <bi...@gmail.com>.
I have a test case where I am using CLIENT_ACK on consumer side and also
using session.recovery()
In this case, message redelivery is expected, right ? (according to
http://activemq.apache.org/message-redelivery-and-dlq-handling.html)
and what if my consumer throws exception and continuous to run: Here after 6
redelivery attempts (by dafault), Will messages still no be sent to the DLQ
?
Please correct me if I am wrong..
--
View this message in context: http://activemq.2283324.n4.nabble.com/Acknowledgements-and-transacted-sessions-tp4652740p4674992.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Acknowledgements and transacted sessions
Posted by Gary Tully <ga...@gmail.com>.
DLQ ( dead letter) is for failed messages, so messages that are acked
as poison - the consumer saying I cannot delivery this message, I have
retried and it gets rolledback of there is an exception.
If there is client ack, then the message is acked. There is no DLQ processing.
So DLQ processing is the result of a Poison Ack - another type of ack
that indicates a (possibly repeated) failure by the app as seen by the
message consumer
On 29 November 2013 06:09, johnbing <bi...@gmail.com> wrote:
> As you have specified "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) "
>
> I am able to under dlq handling prospective ? I got that redelivery can only
> be achieved by using transactions. But what is the difference in DLQ
> handling in transactions Vs Acknowledgement ?
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/Acknowledgements-and-transacted-sessions-tp4652740p4674935.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
--
http://redhat.com
http://blog.garytully.com
Re: Acknowledgements and transacted sessions
Posted by johnbing <bi...@gmail.com>.
As you have specified "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) "
I am able to under dlq handling prospective ? I got that redelivery can only
be achieved by using transactions. But what is the difference in DLQ
handling in transactions Vs Acknowledgement ?
--
View this message in context: http://activemq.2283324.n4.nabble.com/Acknowledgements-and-transacted-sessions-tp4652740p4674935.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Acknowledgements and transacted sessions
Posted by Gary Tully <ga...@gmail.com>.
> 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 <no...@spamgourmet.com> wrote:
> On Mon, 28 May 2012 15:42:21 +0100, Gary Tully
> <ga...@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
Re: Acknowledgements and transacted sessions
Posted by spam trap <no...@spamgourmet.com>.
On Mon, 28 May 2012 15:42:21 +0100, Gary Tully
<ga...@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.
Re: Acknowledgements and transacted sessions
Posted by Gary Tully <ga...@gmail.com>.
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.
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.
If the overhead of consumer creation is too much, then look at jms
redelivery semantics and a transacted session.
On 28 May 2012 11:00, spam trap <no...@spamgourmet.com> wrote:
> Hi,
>
> Can someone help me understand better the way ActiveMQ handles
> transactions and acknowledgements?
>
> I need to write a consumer that processes a message. If something
> goes wrong or the consumer crashes we need the message to be consumed
> again (when the consumer is restarted).
>
> Should I use CLIENT_ACKNOWLEDGE (with message.acknowledge()) or
> SESSION_TRANSACTED (with a session.commit())?
>
--
http://fusesource.com
http://blog.garytully.com