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 <nospam.1.friedbad...@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
