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-2540) Duplicate suppression lack of recovery with JDBCStore can result in "hung" queue afer failover of outstanding send or transaction.
Date Fri, 18 Dec 2009 13:37:53 GMT

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

Gary Tully commented on AMQ-2540:
---------------------------------

on the audit recovery query limit:
It needs to be maxConcurrentProducers * maxBatchSize * maxDestinations

but with jmstemplate, producers can change with every send, so the maxConcurrentProducers
can be large and also the maxProducersToAudit value needs to be large. 
With interleaving there can be quite a collection of outstanding producers and transactions.

> Duplicate suppression lack of recovery with JDBCStore can result in "hung" queue afer
failover of outstanding send or transaction.
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2540
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2540
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Message Store
>    Affects Versions: 5.3.0
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>             Fix For: 5.4.0
>
>
> during failover, when a commit or send reply is lost, such that the broker has completed
the operation but the client does not see the reply, the operation and context will be replayed.
This results in duplicate messages that should be suppressed. The AMQ reference store does
this correctly but the audit check in the JDBCMessageStore does not do recovery so it is unaware
of past events. 
> Adding some replay capability to the audit resolves this as it can then suppress duplicated.
> The audit depth should limit the replay depth.
> {code}<jdbcPersistenceAdapter dataSource="#...." maxProducersToAudit="10000"/>{code}

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