activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r932305 - in /websites/production/activemq/content: cache/main.pageCache why-do-kahadb-log-files-remain-after-cleanup.html
Date Thu, 11 Dec 2014 14:21:13 GMT
Author: buildbot
Date: Thu Dec 11 14:21:12 2014
New Revision: 932305

Log:
Production update by buildbot for activemq

Modified:
    websites/production/activemq/content/cache/main.pageCache
    websites/production/activemq/content/why-do-kahadb-log-files-remain-after-cleanup.html

Modified: websites/production/activemq/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/activemq/content/why-do-kahadb-log-files-remain-after-cleanup.html
==============================================================================
--- websites/production/activemq/content/why-do-kahadb-log-files-remain-after-cleanup.html
(original)
+++ websites/production/activemq/content/why-do-kahadb-log-files-remain-after-cleanup.html
Thu Dec 11 14:21:12 2014
@@ -102,7 +102,18 @@ log4j.logger.org.apache.activemq.store.k
  TRACE | gc candidates after dest:0:J, [87] | org.apache.activemq.store.kahadb.MessageDatabase
| ActiveMQ Journal Checkpoint Worker
  TRACE | gc candidates: [87] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ
Journal Checkpoint Worker
  DEBUG | Cleanup removing the data files: [87] | org.apache.activemq.store.kahadb.MessageDatabase
| ActiveMQ Journal Checkpoint Worker]]></script>
-</div></div><p>We get one candidate, data-87.log from the existing set
of journal data files <code>[86, 87, 163, 164]</code>. There is a current transaction
using 164, destination (Queue named E) <code>'0\:E'</code> has some messages in
163, destination <code>'0:I'</code> has messages in 86 and 87 is unreferenced.
In this case, there must be some long standing unacked messages or a very slow consumer on
destination <code>'0:I'</code>.<br clear="none"> The <code>'0:'</code>
prefix is shorthand for a queue, <code>'1:'</code> for a topic, i.e: <code>dest:1:B</code>
is a topic named B.</p></div>
+</div></div><p>We get one candidate, data-87.log from the existing set
of journal data files <code>[86, 87, 163, 164]</code>. There is a current transaction
using 164, destination (Queue named E) <code>'0\:E'</code> has some messages in
163, destination <code>'0:I'</code> has messages in 86 and 87 is unreferenced.
In this case, there must be some long standing unacked messages or a very slow consumer on
destination <code>'0:I'</code>.<br clear="none"> The <code>'0:'</code>
prefix is shorthand for a queue, <code>'1:'</code> for a topic, i.e: <code>dest:1:B</code>
is a topic named B.</p><p>&#160;</p><p>&#160;</p><hr><h3
id="WhydoKahaDBlogfilesremainaftercleanup?-Non-persistentmessages">Non-persistent messages</h3><p>Similar
for non-persistent messages that are not stored in your configured KahaDB persistence adapter
but get swapped to temp storage once they exceed the broker's configured memoryUsage limit.
A similar logging configuration can show details of the cleanup of temp storage
 .</p><p>&#160;</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[log4j.appender.kahadb=org.apache.log4j.RollingFileAppender
+log4j.appender.kahadb.file=${activemq.base}/data/kahadb.log
+log4j.appender.kahadb.maxFileSize=1024KB
+log4j.appender.kahadb.maxBackupIndex=5
+log4j.appender.kahadb.append=true
+log4j.appender.kahadb.layout=org.apache.log4j.PatternLayout
+log4j.appender.kahadb.layout.ConversionPattern=%d [%-15.15t] %-5p %-30.30c{1} - %m%n
+log4j.logger.org.apache.activemq.store.kahadb=TRACE, kahadb
+log4j.logger.org.apache.activemq.store.kahadb.MessageDatabase=INFO, kahadb
+ ]]></script>
+</div></div><p>&#160;</p><p>Note the last line of above
logging configuration disables the verbose logging of the kahadb cleanup task. If that line
gets removed, the cleanup details of both kahadb and temp storage will be logged to the same
file but you need to be careful not to mix the logging output.</p></div>
         </td>
         <td valign="top">
           <div class="navigation">



Mime
View raw message