[
https://issues.apache.org/jira/browse/AMQNET-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish reopened AMQNET-394:
---------------------------------
Actually I think this solution is not so great, the simplest solution would be
for the FailoverTransport to not create the zombie consumers in the first
place. This can be accomplished by adding the missing call to:
{code}
stateTracker.Track(command);
{code}
In FailoverTransport oneway:
{code}
else if(command.IsRemoveInfo || command.IsMessageAck)
{
stateTracker.Track(command);
// Simulate response to RemoveInfo command or a
MessageAck
// since it would be stale at this point.
if(command.ResponseRequired)
{
OnCommand(this, new Response() { CorrelationId =
command.CommandId });
}
return;
}
{code}
This then also accounts for Producers and Sessions which the applied change
does not.
> Zombie Consumer is created after failover
> -----------------------------------------
>
> Key: AMQNET-394
> URL: https://issues.apache.org/jira/browse/AMQNET-394
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, Stomp
> Affects Versions: 1.5.6
> Reporter: Jim Gomes
> Assignee: Jim Gomes
> Priority: Critical
> Labels: consumer, failover
> Fix For: 1.5.3, 1.5.7, 1.6.0
>
> Original Estimate: 24h
> Time Spent: 24h
> Remaining Estimate: 0h
>
> Steps to reproduce:
> 1. Create a consumer on a topic.
> 2. Disconnect the broker (easiest is to shut it down).
> 3. Destroy the consumer while the low-level failover is retrying to connect.
> 4. Bring the broker online and let the failover reconnect.
> Result:
> A zombie consumer is re-created on the topic. This will eventually lead to
> producer flow-control kicking in because it will never acknowledge messages
> sent to it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
