Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Thu, 3 Oct 2013 10:27:44 +0000 (UTC)
From: "Gary Tully (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <JIRA.12648079.1368746937161.6082.1380796064667@arcas>
In-Reply-To: <JIRA.12648079.1368746937161@arcas>
References: <JIRA.12648079.1368746937161@arcas>
Subject: [jira] [Updated] (AMQ-4540) NetworkBridge - don't wait for ever for
 demandSubscription pending send responses on remove
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/AMQ-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Tully updated AMQ-4540:
----------------------------

    Fix Version/s:     (was: 5.9.0)
                   5.10.0

moving to 5.10 - it need not hold up a 5.10

> NetworkBridge - don't wait for ever for demandSubscription pending send responses on remove
> -------------------------------------------------------------------------------------------
>
>                 Key: AMQ-4540
>                 URL: https://issues.apache.org/jira/browse/AMQ-4540
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.8.0
>            Reporter: Gary Tully
>             Fix For: 5.10.0
>
>         Attachments: NetworkBridgeRemoveInflightTest.java
>
>
> In a networkbridge, a demandSub tracks outstanding asyncRquests and waits for them to complete on removal such that the messages can be acked correctly when the send completes.
> If the send is blocked on pfc on the remote broker, it may not return for some time, which blocks other removals leaving messages stuck inflight to networked subscriptions.
> The wait ensures that a message send will not be a duplicate, but blocking for ever does not make sense, especially considering that removes are serialised.
> We need some openwire command that can cancel pending sends to sort out this case but even then we need to timeout at some stage in case the other end cannot respond.


--
This message was sent by Atlassian JIRA
(v6.1#6144)