> 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.friedbad...@spamgourmet.com> wrote: > On Mon, 28 May 2012 15:42:21 +0100, Gary Tully > <gary.tu...@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
