Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Thu, 24 Nov 2011 15:30:40 +0000 (UTC)
From: "Gary Tully (Reopened) (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <1797076888.9969.1322148640030.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <508602340.51121.1320253532241.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Reopened] (AMQ-3576) ProducerBrokerExchange last producer
 sequenceId initialization needs runtime updates to deal with possible
 duplicate resends
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Gary Tully reopened AMQ-3576:
-----------------------------


The default true for auditNetworkProducers needs more consideration. networkConnector audit is problematic for composite destinations and virtual topics and when conduit=false b/c the source broker generates the duplicates, independent of a producer.
When none of the above features are enabled, a vanilla network, the audit is valuable to catch the case where a reply is lost to a successful send.
                
> ProducerBrokerExchange last producer sequenceId initialization needs runtime updates to deal with possible duplicate resends
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-3576
>                 URL: https://issues.apache.org/jira/browse/AMQ-3576
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.5.1
>         Environment: failover:(tcp://host:port?soWriteTimeout=500)?jms.useAsyncSend=true&trackMessages=true
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>             Fix For: 5.6.0
>
>
> Under load, a  buffered pending send can be replayed along with a failover replay (writeTimeFilter initiated) which can miss the audit b/c it won't have knowledge of the original send.
> The dispatch decision is based on the current stored state at the time of reconnect with the expectation that the next message will not be duplicated. It seems under some load and tcp buffering conditions this is possible to get duplicate sends of new messages.
>  

--
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