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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

buildbot
Author: buildbot
Date: Mon Dec  4 18:24:25 2017
New Revision: 1021713

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 Mon Dec  4 18:24:25 2017
@@ -102,7 +102,7 @@ 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</pre>
-</div></div><p>We get one candidate,&#160;<strong><code>data-87.log</code></strong> from the existing set of journal data files <strong><code>[86, 87, 163, 164]</code></strong>. There is a current transaction using <strong><code>164</code></strong>, destination (Queue named&#160;<strong><code>E</code></strong>) <code>'<strong>0:E</strong>'</code> has some messages in <strong><code>163</code></strong>, destination <code>'<strong>0:I</strong>'</code> has messages in&#160;<strong><code>86</code></strong> and&#160;<strong><code>87</code></strong> is un-referenced. In this case, there must be some long standing un-acknowledged messages or a very slow consumer on destination <code>'<strong>0:I</strong>'</code>.</p><div class="confluence-information-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body">The <code>'<strong>0:</strong>'</code> prefix is sho
 rthand for a queue, <code>'<strong>1:</strong>'</code> for a topic. Example: <strong><code>dest:1:B</code></strong> refers to a topic named <strong><code>B</code></strong>.</div></div><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&#160;<strong><code>memoryUsage</code></strong> 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">
+</div></div><p>We get one candidate,&#160;<strong><code>data-87.log</code></strong> from the existing set of journal data files <strong><code>[86, 87, 163, 164]</code></strong>. There is a current transaction using <strong><code>164</code></strong>, destination (Queue named&#160;<strong><code>E</code></strong>) <code>'<strong>0:E</strong>'</code> has some messages in <strong><code>163</code></strong>, destination <code>'<strong>0:I</strong>'</code> has messages in&#160;<strong><code>86</code></strong> and&#160;<strong><code>87</code></strong> is un-referenced. In this case, there must be some long standing un-acknowledged messages or a very slow consumer on destination <code>'<strong>0:I</strong>'</code>.</p><div class="confluence-information-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>The <code>'<strong>0:</strong>'</code> prefix is
 shorthand for a queue, <code>'<strong>1:</strong>'</code> for a topic. Example: <strong><code>dest:1:B</code></strong> refers to a topic named <strong><code>B</code></strong>.</p></div></div><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&#160;<strong><code>memoryUsage</code></strong> 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">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">log4j.appender.kahadb=org.apache.log4j.RollingFileAppender
 log4j.appender.kahadb.file=${activemq.base}/data/kahadb.log
 log4j.appender.kahadb.maxFileSize=1024KB