activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-2210) Infinite loop: WARN PrefetchSubscription - Ack before disaptch, waiting for recovery dispatch: MessageAck
Date Thu, 16 Apr 2009 15:36:33 GMT

    [ 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.


Mime
View raw message