activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: ActiveMQ 5.4.0: receiving warnings whenever a broker is stopped/restarted
Date Thu, 09 Sep 2010 10:40:39 GMT
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:

On 8 September 2010 22:11, Colleen Velo <> 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:*


Open Source Integration

View raw message