activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQCPP-363) failover: consumer does not always restart properly after reconnect
Date Thu, 21 Apr 2011 13:12:05 GMT

    [ https://issues.apache.org/jira/browse/AMQCPP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022736#comment-13022736
] 

Timothy Bish commented on AMQCPP-363:
-------------------------------------

It would most likely still be an issue on 5.3 series and older brokers, you can open a new
issue if you want me to try and work around the issue, although the current behaviour is a
result of fixing other issues on those brokers so it still may not work as you expect it to.


If the duplicates are from the message that was being received in onMessage at the time of
failover then the duplicate is expected, AMQCPP doesn't have the duplicate filtering mechanisms
that the Java client has so a duplicate message on failover isn't to surprising.  You can
open an issue if you like, but I have no idea when I would be able to add that functionality,
you can always contribute it of course :)


> 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

Mime
View raw message