activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <>
Subject [jira] [Resolved] (AMQ-2922) Add ability for KahaDB log files to be created on a per-destination basis.
Date Tue, 13 Sep 2011 17:51:09 GMT


Gary Tully resolved AMQ-2922.

    Resolution: Fixed

Added a new multi kahaDB persistence adapter that supports distributing destinations across
n kahaDB adapters.
It is configured with a list of kahaDBs that are filtered using a destination wildcard (like
a policy entry). A filteredKahaDB entry without a destination will match everything. When
transactions include destinations that cross persistence adapters, two phase completion is
used so there is performance penalty. It is best to keep transactions to a single persistence
Each kahaDB instance can be configured at will.

            <mKahaDB directory="${activemq.base}/data/kahadb">
               <!-- just all queues -->
               <filteredKahaDB queue=">">
                  <kahaDB />
               <!-- everything -->
                  <kahaDB />

> Add ability for KahaDB log files to be created on a per-destination basis.
> --------------------------------------------------------------------------
>                 Key: AMQ-2922
>                 URL:
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: Message Store
>    Affects Versions: 5.4.0
>         Environment: All
>            Reporter: Peter Blackburn
>            Assignee: Gary Tully
>             Fix For: 5.6.0
>         Attachments: activemq.xml, multistore.diff
> KahaDB persistence uses rolling log files to store unconsumed messages. These are named
db-1.log, db-2.log ... db3.log. At present these files contain messages for all destinations
managed by the broker.
> A configurable option could be added that would allow these files to be created on a
per-destination basis. For example, if the broker contained two queue destinations, queue_1
and queue_2, the log files would become:
> queue_1-1.log, queue_1-2.log....etc
> queue_2-1.log, queue_2-2.log....etc
> Each set of log files would only contain messages for the relevant destination. 
> This would help in the following situation:
> queue_1: receives one message every 15 seconds or so. These messages remain unconsumed
for several hours.
> queue_2: receives thousands of messages per second. These messages are consumed as they
> At present, the scenario above leads to each log files containing a few messages that
have yet to be consumed and thousands of messages that have been consumed, but the log file
cannot be deleted until all messages logged in it have been consumed (which may be hours later).
> Logging on a per-destination basis would allow the log files for queue_2 in the above
example to be deleted, meaning the unconsumed messages on queue_1 take up far less disk space.
This would also reduce the number of file handles required.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message