[
https://issues.apache.org/jira/browse/AMQ-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13138387#comment-13138387
]
Gary Tully commented on AMQ-3569:
---------------------------------
Am thinking that a fault tolerant connection should register/unregister with
the broker store b/c we don't want a persisted audit trail for a failed
connection to go away, irrespective of how long it remains disconnected.
We need only track a range of producer sequence ids for connections we are
interested in. A normal shutdown of a connection will unregistered it from the
audit but in the failed case, there will be no shutdown command, so it will
persist till the reconnect.
This will incur an additional connection setup cost for a fault tolerant
connection, but for duplicate suppression it is worth it. Connections should be
pooled in any event.
This will get away from the need for an LRU cache with eviction which is prone
to time and application resource usage patterns.
> kahaDB producerAudit LRU cache configuration is time dependent, it should not
> be..
> ----------------------------------------------------------------------------------
>
> Key: AMQ-3569
> URL: https://issues.apache.org/jira/browse/AMQ-3569
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Message Store
> Affects Versions: 5.5.0, 5.5.1
> Reporter: Gary Tully
> Assignee: Gary Tully
> Labels: audit, duplicate, failover
> Fix For: 5.6.0
>
>
> The failover: reconnect logic can submit duplicate messages, if a send reply
> is lost. this is trapped by the producerAudit. The audit keeps an LRU cache
> of producerIds and message sequence ids. The default value is 64. This is a
> little small if many producers come and go. It can be configured via:
> {code}<kahaDB ... maxFailoverProducersToTrack="2048" />{code}. The problem
> is picking a value.
> If a connection is down for an indeterminate time, the number of producers
> that will be seen by the audit is indeterminate. It can be made very large,
> but this will consume memory resources. The audit needs to be maintained on a
> connection basis. This will suffer from the same problem, how many
> connections to audit, but with connection pools this can be mitigated better
> than producers.
--
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
