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 (< 4), Default (= 4) and High (>
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 >= 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">
