Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Thu, 24 Nov 2011 17:07:40 +0000 (UTC)
From: "Gary Tully (Issue Comment Edited) (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <2025012230.10259.1322154460166.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <508602340.51121.1320253532241.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (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:comment-tabpanel&focusedCommentId=13143283#comment-13143283 ] 

Gary Tully edited comment on AMQ-3576 at 11/24/11 5:06 PM:
-----------------------------------------------------------

The network connector case needs some special treatment. In a network connector, a single producer resends messages from multiple original producers so a single audit does not make sense as it will depends on sequence order across producers, which is not probable.
The solution for network connector producers requires querying the persistence adapter before each send. This will place additional synchronization contention on the store so if duplicates are not a problem it can be disabled. There is a new boolean {{auditNetworkProducers}} attribute on a TransportConnector that toggles the behavior. It defaults to -true- false.

Update in: http://svn.apache.org/viewvc?rev=1197203&view=rev
                
      was (Author: gtully):
    The network connector case needs some special treatment. In a network connector, a single producer resends messages from multiple original producers so a single audit does not make sense as it will depends on sequence order across producers, which is not probable.
The solution for network connector producers requires querying the persistence adapter before each send. This will place additional synchronization contention on the store so if duplicates are not a problem it can be disabled. There is a new boolean {{auditNetworkProducers}} attribute on a TransportConnector that toggles the behavior. It defaults to true.

Update in: http://svn.apache.org/viewvc?rev=1197203&view=rev
                  
> 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