You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@activemq.apache.org by cl...@apache.org on 2019/10/23 15:51:57 UTC
[activemq-website] branch master updated: Update message-groups.md
This is an automated email from the ASF dual-hosted git repository.
clebertsuconic pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/activemq-website.git
The following commit(s) were added to refs/heads/master by this push:
new 7c68733 Update message-groups.md
new 14471b2 This closes #20
7c68733 is described below
commit 7c6873315b28078f1db659121c87591021692394
Author: Jérôme BAROTIN <je...@gmail.com>
AuthorDate: Wed Oct 23 14:26:14 2019 +0200
Update message-groups.md
Add example to show how to enable messageGroupMapFactory and simpleMessageGroupMapFactory though XML config
---
content/message-groups.html | 40 ++++++++++++++++++++++++++++++++--------
src/message-groups.md | 44 +++++++++++++++++++++++++++++++++++---------
2 files changed, 67 insertions(+), 17 deletions(-)
diff --git a/content/message-groups.html b/content/message-groups.html
index 32846c8..cacd651 100644
--- a/content/message-groups.html
+++ b/content/message-groups.html
@@ -216,19 +216,44 @@ if (message.getBooleanProperty("JMSXGroupFirstForConsumer")) {
<h3 id="competing-demands-of-memory-consumption-load-balancing-complexity-etc">Competing demands of memory consumption, load balancing, complexity, etc.</h3>
-<p>The default behavior which is limited to 1024 message groups in an LRU cache may not match you expectation w.r.t message order… some detail to explain:</p>
+<p>The default behavior called <code class="highlighter-rouge">CachedMessageGroupMap</code> is limited to 1024 message groups in an LRU cache may not match you expectation w.r.t message order. <code class="highlighter-rouge">CachedMessageGroupMap</code> has bounded memory use, but only keeps track of up to 1024 (or the maximum configured size) groups, then loses track of any groups older than the newest 1024. In this way, if there are more groups than the maximum, <strong>ordering will b [...]
-<p>MessageGroupHashBucket and SimpleMessageGroupMap message groups work by associating each group with a consumer.</p>
+<p>Typically users would close groups such that the in memory set can be retained below the configured limits. Some usefull discussion at <a href="https://issues.apache.org/jira/browse/AMQ-6851">AMQ-6851</a></p>
+
+<p>In order to prevent this limitation you can use <code class="highlighter-rouge">MessageGroupHashBucket</code> or <code class="highlighter-rouge">SimpleMessageGroupMap</code>. Their are working by associating each group with a consumer.</p>
-<p>SimpleMessageGroupMap keeps track of every group but suffers from unbounded memory use.</p>
+<p><code class="highlighter-rouge">SimpleMessageGroupMap</code> keeps track of every group but suffers from unbounded memory use.</p>
-<p>MessageGroupHashBucked keeps track of every group and has bounded memory use.</p>
+<p>The following code snippet shows how to enable it :</p>
-<p>CachedMessageGroupMap has bounded memory use, but only keeps track of up to 1024 (or the maximum configured size) groups, then loses track of any groups older than the newest 1024.</p>
+<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code><destinationPolicy>
+ <policyMap>
+ <policyEntries>
+ <policyEntry queue=">">
+ <messageGroupMapFactory>
+ <simpleMessageGroupMapFactory/>
+ </messageGroupMapFactory>
+ </policyEntry>
+ </policyEntries>
+ </policyMap>
+</destinationPolicy>
-<p>In this way, if there are more groups than the maximum, <strong>ordering will be lost for the oldest groups</strong>.</p>
+</code></pre></div></div>
-<p>Typically users would close groups such that the in memory set can be retained below the configured limits. Some usefull discussion at <a href="https://issues.apache.org/jira/browse/AMQ-6851">AMQ-6851</a></p>
+<p><code class="highlighter-rouge">MessageGroupHashBucked</code> keeps track of every group and has bounded memory use. The following code snippet shows how to enable it :</p>
+
+<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code><destinationPolicy>
+ <policyMap>
+ <policyEntries>
+ <policyEntry queue=">">
+ <messageGroupMapFactory>
+ <messageGroupHashBucked cachedSize=1024 />
+ </messageGroupMapFactory>
+ </policyEntry>
+ </policyEntries>
+ </policyMap>
+</destinationPolicy>
+</code></pre></div></div>
<h3 id="see">See</h3>
@@ -236,7 +261,6 @@ if (message.getBooleanProperty("JMSXGroupFirstForConsumer")) {
<li><a href="how-do-message-groups-compare-to-selectors">How do Message Groups compare to Selectors</a></li>
</ul>
-
</div>
</div>
</div>
diff --git a/src/message-groups.md b/src/message-groups.md
index 9e79304..19468c4 100644
--- a/src/message-groups.md
+++ b/src/message-groups.md
@@ -1,6 +1,6 @@
---
layout: default_md
-title: Message Groups
+title: Message Groups
title-class: page-title-activemq5
type: activemq5
---
@@ -131,21 +131,47 @@ As [the appropriate test case](https://github.com/apache/activemq/blob/master/ac
### Competing demands of memory consumption, load balancing, complexity, etc.
-The default behavior which is limited to 1024 message groups in an LRU cache may not match you expectation w.r.t message order... some detail to explain:
+The default behavior called `CachedMessageGroupMap` is limited to 1024 message groups in an LRU cache may not match you expectation w.r.t message order. `CachedMessageGroupMap` has bounded memory use, but only keeps track of up to 1024 (or the maximum configured size) groups, then loses track of any groups older than the newest 1024. In this way, if there are more groups than the maximum, **ordering will be lost for the oldest groups**.
-MessageGroupHashBucket and SimpleMessageGroupMap message groups work by associating each group with a consumer.
+Typically users would close groups such that the in memory set can be retained below the configured limits. Some usefull discussion at [AMQ-6851](https://issues.apache.org/jira/browse/AMQ-6851)
-SimpleMessageGroupMap keeps track of every group but suffers from unbounded memory use.
+In order to prevent this limitation you can use `MessageGroupHashBucket` or `SimpleMessageGroupMap`. Their are working by associating each group with a consumer.
-MessageGroupHashBucked keeps track of every group and has bounded memory use.
+`SimpleMessageGroupMap` keeps track of every group but suffers from unbounded memory use.
-CachedMessageGroupMap has bounded memory use, but only keeps track of up to 1024 (or the maximum configured size) groups, then loses track of any groups older than the newest 1024.
+The following code snippet shows how to enable it :
-In this way, if there are more groups than the maximum, **ordering will be lost for the oldest groups**.
+```
+<destinationPolicy>
+ <policyMap>
+ <policyEntries>
+ <policyEntry queue=">">
+ <messageGroupMapFactory>
+ <simpleMessageGroupMapFactory/>
+ </messageGroupMapFactory>
+ </policyEntry>
+ </policyEntries>
+ </policyMap>
+</destinationPolicy>
-Typically users would close groups such that the in memory set can be retained below the configured limits. Some usefull discussion at [AMQ-6851](https://issues.apache.org/jira/browse/AMQ-6851)
+```
+
+`MessageGroupHashBucked` keeps track of every group and has bounded memory use. The following code snippet shows how to enable it :
+
+```
+<destinationPolicy>
+ <policyMap>
+ <policyEntries>
+ <policyEntry queue=">">
+ <messageGroupMapFactory>
+ <messageGroupHashBucked cachedSize=1024 />
+ </messageGroupMapFactory>
+ </policyEntry>
+ </policyEntries>
+ </policyMap>
+</destinationPolicy>
+```
### See
* [How do Message Groups compare to Selectors](how-do-message-groups-compare-to-selectors)
-