Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 9 Nov 2011 15:17:51 +0000 (UTC)
From: =?utf-8?Q?Daniel_La=C3=BCgt_=28Commented=29_=28JIRA=29?=
 <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <397596738.14551.1320851871873.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1382394161.14470.1320850791583.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (AMQCPP-384) Failover and prefetch=0 can result
 in hung consumers if the MessagePull command is lost
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/AMQCPP-384?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1314=
7090#comment-13147090 ]=20

Daniel La=C3=BCgt commented on AMQCPP-384:
-------------------------------------

Ok I've ticked the license grant option.
               =20
> Failover and prefetch=3D0 can result in hung consumers if the MessagePull=
 command is lost
> -------------------------------------------------------------------------=
--------------
>
>                 Key: AMQCPP-384
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-384
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>    Affects Versions: 3.4.0
>            Reporter: Daniel La=C3=BCgt
>            Assignee: Timothy Bish
>         Attachments: ConnectionStateTracker.cpp.diff, ConnectionStateTrac=
ker.h.diff
>
>
> The problem has been fixed in ActiveMQ Java Client with the issue AMQ-287=
7:
> https://issues.apache.org/jira/browse/AMQ-2877
> I've attached a patch that backport the fix done in java to C++. It can b=
e probably used as suggestion...
> With prefetch=3D0, a consumer that has no messages sends an async message=
 to the broker to have it dispatch a single message and waits for the dispa=
tch to ocurr. prefetch=3D0 makes the consumer a pull consumer, in that it h=
as to ask for a message each time.
> there is a possibility that failover occurs just after the send of the me=
ssagePull command such that the consumer is blocked waiting for a message b=
ut 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 comma=
nds, keeping one outstanding reference for each consumer/destination pair t=
hat 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 administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira