[
https://issues.apache.org/activemq/browse/AMQ-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51229#action_51229
]
Gary Tully commented on AMQ-2210:
---------------------------------
The intention of that wait is to allow a master/slave broker to start or
restart and redeliver messages before an outstanding ack from a client is
processed. In a network of brokers scenario, any unacked message will remain on
the original broker so it will never get redelivered. In this case, it makes
sense to get an unmatched ack exception.
The simple fix is to limit that wait to a few seconds and process the ack in
the normal way even if the wait expires. Worst case scenario there is an
unmatched ack exception and the message is eventually redelivered and should be
seen as a duplicate.
So failover among a network of brokers will always be a little more lossy in
terms of message ordering than master slave.
> Infinite loop: WARN PrefetchSubscription - Ack before disaptch,
> waiting for recovery dispatch: MessageAck
> --------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-2210
> URL: https://issues.apache.org/activemq/browse/AMQ-2210
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.2.0
> Environment: solaris 10 trunk version 764403
> Reporter: ying
> Priority: Blocker
> Fix For: 5.3.0
>
>
> Reproduce steps:
> 1. setup 4 network of brokers with multicast discovery
> 2. start client consumers and producers
> 3. let the producer produce message constantly
> 4. in jconsole, stop() the broker the consumers are connecting to
> 5. after the consumers failover to another broker, the newly connected broker
> will get into an infinite loop:
> WARN PrefetchSubscription - Ack before disaptch, waiting for
> recovery dispatch: MessageAck {commandId = 1232, responseRequired = true,
> ackType = 2, consumerId = ID:host01-39430-1239887122787-0:0:2:1,
> firstMessageId = ID:host01-39430-1239887122787-0:0:87:1:5, lastMessageId =
> ID:host01-39430-1239887122787-0:0:87:1:5, destination =
> queue://Consumer.A-host01-1527-1239887124983.VirtualTopic.B, transactionId =
> TX:ID:host01-39430-1239887122787-0:0:38, messageCount = 1}
> This broker will stop functioning and consumer is not processing messages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
