This warning can largely be ignored but in a particular case where failover reconnect occurs to another broker or to another consumer, it can result in a duplicate message dispatch to a consumer. This warning can help to identify that case.
In essence it means that failover reconnect has kicked in with an outstanding ack. Either the ack was delivered successfully or not. The consumer cannot know, so it replays the ack. The broker has received the ack but has not dispatched any messages to that consumer. So it is ignoring the ack. If the original ack was not received successfully by the broker, the original message will be replayed. If it is replayed to the same consumer (or any consumer on the same connection) it will be ignored as a duplicate. If it is replayed to a consumer on a different connection, it will be a duplicate delivery that will not be automatically ignored. This is a potential problem for non idempotent application operations so the possibility is flagged as a warning. Acks are very important so ignoring an ack is not the norm. It is something that must be dealt with by the failover transport and an event that some class of applications need to deal with by using transactions. The use of transactions can make this failover behavior more deterministic, in a transacted consumer case, the transaction would rollback if it has an outstanding ack and does not get the corresponding duplicate redelivery. In the case that an outstanding commit operation is in progress at failover, the transaction is forced to rollback as 'in doubt' . In this way, the user can be made aware of the potential failed ack delivery and subsequent possible duplicate delivery. Maybe that is all "too much information", but if your application uses a HA setup and requires exactly received once semantics across all failover scenarios, this warning is an indication that you need to consider using transacted sessions for your consumers. Some more reference material: http://activemq.apache.org/failover-transport-reference.html#FailoverTransportReference-Transactions On 8 September 2010 22:11, Colleen Velo <cmv...@gmail.com> wrote: > Receiving lots of these messages on the remaining active brokers, whenever I > stop a broker (that still has messages on the queue): > > *2010-09-08 16:03:25,571 [2.100.216:53706] WARN PrefetchSubscription > - Ignoring ack received before dispatch; result of failover with an > outstanding ack. Acked messages will be replayed if present on this broker. > Ignored ack: MessageAck {commandId = 18926, responseRequired = false, > ackType = 2, consumerId = > ID:pubd-pubdee2-path1-57307-1283870949127-0:5:16:1, firstMessageId = > ID:pubd-amq2-path1-48293-1283979729663-6:12:-1:1:1, lastMessageId = > ID:pubd-amq2-path1-48293-1283979729663-6:12:-1:1:1, destination = > queue://ibsys.content.publication, transactionId = > TX:ID:pubd-pubdee2-path1-57307-1283870949127-0:5:6274, messageCount = 1}* > > > Current setup: > I am currently using *ActiveMQ 5.4.0*. > > • 3 producers > • 3 brokers (configured as a network of brokers) > • 3 consumers > > > Thoughts? > > Thanks, > > -- > Colleen Velo > *email: cmv...@gmail.com* > -- http://blog.garytully.com Open Source Integration http://fusesource.com
