[
https://issues.apache.org/jira/browse/AMQCPP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Hoffmann updated AMQCPP-363:
----------------------------------
Description:
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
was:
Hi,
While testing AMQCPP-355, we came across a problem of 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
> 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.3.1
>
>
> 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
