activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (Commented) (JIRA)" <>
Subject [jira] [Commented] (AMQ-3569) kahaDB producerAudit LRU cache configuration is time dependent, it should not be..
Date Fri, 28 Oct 2011 14:12:32 GMT


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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message