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