activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQ-3576) ProducerBrokerExchange last producer sequenceId initialization needs runtime updates to deal with possible duplicate resends
Date Wed, 02 Nov 2011 17:25:32 GMT

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

Gary Tully updated AMQ-3576:
----------------------------

    Description: 
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.
 

  was: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.

    Environment: failover:(tcp://host:port?soWriteTimeout=500)?jms.useAsyncSend=true&trackMessages=true
    
> 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
>             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

        

Mime
View raw message