svn commit: r856809 - in /websites/production/activemq/content: cache/main.pageCache how-can-i-support-priority-queues.html

[bu...@apache.org]

Author: buildbot
Date: Mon Apr  1 01:21:59 2013
New Revision: 856809

Log:
Production update by buildbot for activemq

Modified:
    websites/production/activemq/content/cache/main.pageCache
    websites/production/activemq/content/how-can-i-support-priority-queues.html

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

Modified: websites/production/activemq/content/how-can-i-support-priority-queues.html
==============================================================================
--- websites/production/activemq/content/how-can-i-support-priority-queues.html (original)
+++ websites/production/activemq/content/how-can-i-support-priority-queues.html Mon Apr  1 01:21:59 2013
@@ -91,7 +91,7 @@
 
 <p>The full range of priority values (0-9) are supported by the <a shape="rect" href="jdbc-support.html" title="JDBC Support">JDBC</a> message store. For <a shape="rect" href="kahadb.html" title="KahaDB">KahaDB</a> three priority categories are supported, Low (&lt; 4), Default (= 4) and High (&gt; 4).</p>
 
-<p>Since the message cursors (and client side) implement strict ordering of priorities, it's possible to observe strict priority ordering if message dispatching can happen from the cache and not have to hit the disk (i.e., your consumers are fast enough to keep up with producers), or if you're using non-persistent messages that never have to flush to disk (which happens by default using the FilePendingMessageCursor). However, once you hit a situation where consumers are slow, or producers are just significantly faster, you'll observe that the cache will fill up (possibly with lower priority messages) while higher priority messages get stuck on disk and not available until they're paged in. In this case, you can make a decision to tradeoff optimized message dispatching for priority enforcement. You can disable the cache, message expiration check, and lower you consumer prefetch to 1 to ensure getting the high priority messages from the store ahead of lower priority messages:<
 /p>
+<p>Since the message cursors (and client side) implement strict ordering of priorities, it's possible to observe strict priority ordering if message dispatching can happen from the cache and not have to hit the disk (i.e., your consumers are fast enough to keep up with producers), or if you're using non-persistent messages that never have to flush to disk (using the FilePendingMessageCursor). However, once you hit a situation where consumers are slow, or producers are just significantly faster, you'll observe that the cache will fill up (possibly with lower priority messages) while higher priority messages get stuck on disk and not available until they're paged in. In this case, you can make a decision to tradeoff optimized message dispatching for priority enforcement. You can disable the cache, message expiration check, and lower you consumer prefetch to 1 to ensure getting the high priority messages from the store ahead of lower priority messages Note, this sort of tradeof
 f can have significant performance implications, so you must test your scenarios thoroughly. :</p>
 
 
 <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
@@ -130,7 +130,6 @@ JMSPriority &gt;= 4
 <p>You can reorder messages on some input queue A and send them to queue B in sorted order to avoid having to change your clients. This avoids the need to use selectors in your application as shown above.</p>
 
 <p>To do this use the <a shape="rect" class="external-link" href="http://activemq.apache.org/camel/resequencer.html">Resequencer</a> from the <a shape="rect" href="enterprise-integration-patterns.html" title="Enterprise Integration Patterns">Enterprise Integration Patterns</a></p>
-
           </div>
         </td>
         <td valign="top">