[
https://issues.apache.org/jira/browse/AMQCPP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022778#comment-13022778
]
Timothy Bish commented on AMQCPP-363:
-------------------------------------
AMQCPP-364 fixes the older broker issue, patches applied to the 3.4 branch.
Testers welcome.
> failover: consumer does not always restart properly after reconnect
> -------------------------------------------------------------------
>
> Key: AMQCPP-363
> URL: https://issues.apache.org/jira/browse/AMQCPP-363
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: CMS Impl
> Affects Versions: 3.3.0
> Environment: GNU Linux
> Reporter: Chris Hoffmann
> Assignee: Timothy Bish
> Priority: Critical
> Fix For: 3.4.0
>
>
> Hi,
> While testing AMQCPP-355, we came across a problem when resuming from a
> broker restart. Resuming seems to be erratic when the broker shutdown happens
> during message processing in an onMessage callback.
> a) if a message is ack'ed while the broker is still down, the same message
> will be redelivered after connection resumes. The command tracing does not
> show the sending of the 1st acknowledgment.
> b) if a message is ack'ed after the broker is brought back (connection
> resumed OK), the command tracing shows that the ack is send, but on the
> broker side we see an warning message:
> WARN | 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 = 22, responseRequired = false, ackType =
> 2, consumerId = ID:hostname-44923-1303316424844-0:0:0:0,
> firstMessageId = ID:hostname-58084-1303317597544-0:0:0:0:0,
> lastMessageId = ID:hostname-58084-1303317597544-0:0:0:0:0,
> destination = queue://test, transactionId = null, messageCount = 1,
> poisonCause = null}
> We can't see any redelivery message in the command trace and subsequent
> messages are not delivered either. The consumer is nevertheless shown on
> broker admin console.
> When the connection is resumed, we see that the prefetch size is set to 0 in
> the consumerInfo message.
> c) resuming works fine, if the message is not in process when the shutdown
> happens.
> Cases a+b work fine, when we tried to reproduce with a java client from the
> ActiveMQ examples dir.
> Regards,
> Chris
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
