activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (Commented) (JIRA)" <>
Subject [jira] [Commented] (AMQCPP-384) Failover and prefetch=0 can result in hung consumers if the MessagePull command is lost
Date Wed, 09 Nov 2011 15:03:51 GMT


Timothy Bish commented on AMQCPP-384:

All patches need to be granted apache license on the upload page before they can be added
to the codebase.  You need to update the files and tick the lic grant option.
> Failover and prefetch=0 can result in hung consumers if the MessagePull command is lost
> ---------------------------------------------------------------------------------------
>                 Key: AMQCPP-384
>                 URL:
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>    Affects Versions: 3.4.0
>            Reporter: Daniel Laügt
>            Assignee: Timothy Bish
>         Attachments: ConnectionStateTracker.cpp.diff, ConnectionStateTracker.h.diff
> The problem has been fixed in ActiveMQ Java Client with the issue AMQ-2877:
> I've attached a patch that backport the fix done in java to C++. It can be probably used
as suggestion...
> With prefetch=0, a consumer that has no messages sends an async message to the broker
to have it dispatch a single message and waits for the dispatch to ocurr. prefetch=0 makes
the consumer a pull consumer, in that it has to ask for a message each time.
> there is a possibility that failover occurs just after the send of the messagePull command
such that the consumer is blocked waiting for a message but a failover connection or broker
does not know about the outstanding pull command. The connection state tracker is the normal
mechanism for command replay after failover. This needs to be extended to track messagePull
commands, keeping one outstanding reference for each consumer/destination pair that can be
replayed after failover.
> It makes sense to reuse the messageCache for this.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message