activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-2542) Tidy up store duplicate suppression from failover recovery - consistent store implementation with help from transportConnection
Date Thu, 31 Dec 2009 11:10:42 GMT

    [ https://issues.apache.org/activemq/browse/AMQ-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56710#action_56710
] 

Gary Tully commented on AMQ-2542:
---------------------------------

flag in the producerInfo - set by the failover replay logic.
Some further justification: with many concurrent connections, first recovers fine and producers
messages with a unique producerId per message, this can easily exhaust the recovered message
audit from the store. This makes the store audit a bit useless (unless the maxProducersToAudit
is very large) and points to the fact tat this is the wrong place to do duplicate suppression
in this case.

> Tidy up store duplicate suppression from failover recovery - consistent store implementation
with help from transportConnection
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2542
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2542
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Broker
>    Affects Versions: 5.3.0
>            Reporter: Gary Tully
>             Fix For: 5.4.0
>
>
> With failover - with a failure before a reply is received to a send or a transaction
commit, the send or transaction will be replayed and will be a duplicate.
> The transportConnector should know that recovery/reconnection has happened and should
enforce duplicate suppression based on obtaining the last producer sequence number from the
store.
> Currently, duplicate suppression happens at the jdbc message store add, amq store reference
store etc... it is not consistent and it is abased on a suitable audit window which may be
non deterministic. Would be best to be fully deterministic and consistent (as in a single
persistence adapter api)
> To make this perform, a transportConnection needs to be flagged as a reconnect which
can precipitate the duplicate suppression, possibly needing a wireformat update. This flag
would also help with unmatched acks after failover but maybe that flag can be in an ack...
> This is relevant both when the broker is restarted or when a connection is dropped.
> related issue with relevant test : https://issues.apache.org/activemq/browse/AMQ-2540

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message