Author: buildbot
Date: Fri Feb 22 21:18:13 2013
New Revision: 851582
Log:
Production update by buildbot for camel
Modified:
websites/production/camel/content/cache/main.pageCache
websites/production/camel/content/camel-30-message-store.html
Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/camel/content/camel-30-message-store.html
==============================================================================
--- websites/production/camel/content/camel-30-message-store.html (original)
+++ websites/production/camel/content/camel-30-message-store.html Fri Feb 22
21:18:13 2013
@@ -100,12 +100,16 @@ Implementations would handle the mapping
<div class="panelMacro"><table class="noteMacro"><colgroup span="1"><col
span="1" width="24"><col span="1"></colgroup><tr><td colspan="1" rowspan="1"
valign="top"><img align="middle"
src="https://cwiki.apache.org/confluence/images/icons/emoticons/warning.gif";
width="16" height="16" alt="" border="0"></td><td colspan="1"
rowspan="1"><b>Work in progress</b><br clear="none">Feel free to add, edit,
comment.... At some time we probably need to assign priorities as to what is
indispensable for Camel 3.0 and what could be delivered in a later patch
release</td></tr></table></div>
<ul><li>Generically, entries in a Message Store can be created, updated, read
and deleted.</li><li>Ability to temporarily store exchanges for the following
EIPs:
- <ul><li>Aggregator, Multicast, RecipientList, Splitter : alternative to
AggregationRepository, making it eventually obsolete</li><li>Streaming
Resequencer (CAMEL-949)</li><li>Stream Caching <img align="middle"
class="emoticon"
src="https://cwiki.apache.org/confluence/images/icons/emoticons/help_16.gif";
height="16" width="16" alt="" border="0"></li><li>Claim check</li></ul>
+ <ul><li>Aggregator, Multicast, RecipientList, Splitter : alternative to
AggregationRepository, making it eventually obsolete</li><li>Streaming
Resequencer (CAMEL-949)</li><li>Stream Caching <img align="middle"
class="emoticon"
src="https://cwiki.apache.org/confluence/images/icons/emoticons/help_16.gif";
height="16" width="16" alt="" border="0"></li><li><a shape="rect"
class="external-link" href="http://eaipatterns.com/StoreInLibrary.html";
rel="nofollow">Claim check</a></li></ul>
</li><li>Ability to store exchanges for a defined period of time
<ul><li>Idempotent Consumer</li><li>Dead Letter Queue
(CAMEL-4575)</li><li>Destination for the Tracer</li></ul>
</li><li>Ability to permanently store exchanges (e.g. for audit
trails)</li><li>Provide a certain level of manual retry. That is to get the
original message from the store and feed it back in the originating
route.</li><li>Flexibility to specify what part of an exchange should be stored
(e.g. what exchange properties and message headers) and in which format (e.g.
object serialization, JSON, using encryption)</li><li>Possibility to provide a
filter condition to determine which exchanges should be stored (e.g. only
failed exchanges, only with a certain message header)</li><li>Polling Consumer
to randomly access a message store</li><li>Producer to write an exchange into a
message store</li></ul>
+<ul><li>There is a default message store defined for the Camel Context. This
can be overridden by a route-specific message store. This again can be
overridden by a specific EIP processor.</li></ul>
+
+
+
<h3><a shape="rect" name="Camel3.0-MessageStore-Codeexamples"></a>Code
examples</h3>
<div class="panelMacro"><table class="noteMacro"><colgroup span="1"><col
span="1" width="24"><col span="1"></colgroup><tr><td colspan="1" rowspan="1"
valign="top"><img align="middle"
src="https://cwiki.apache.org/confluence/images/icons/emoticons/warning.gif";
width="16" height="16" alt="" border="0"></td><td colspan="1"
rowspan="1"><b>Work in progress</b><br clear="none">Sometimes it is easier to
express thoughts by providing a fictional piece of code along with some
comments....</td></tr></table></div>
@@ -128,18 +132,22 @@ from(...)
<h5><a shape="rect" name="Camel3.0-MessageStore-Claimcheck"></a>Claim
check</h5>
-<div class="code panel" style="border-width: 1px;"><div class="codeHeader
panelHeader" style="border-bottom-width: 1px;"><b>Setting default message store
for route</b></div><div class="codeContent panelContent">
-<pre class="code-java">
-defaultMessageStore(myStore);
-</pre>
-</div></div>
+<p>THe claim check pattern temporarily reduces the data volume of the message
by storing content in a message store in exchange for a claim check token. The
content is retrieved later on before it's needed again.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeHeader
panelHeader" style="border-bottom-width: 1px;"><b>Claim Check EIP
store</b></div><div class="codeContent panelContent">
<pre class="code-java">
+
+<span class="code-comment">// Optionally: override <span
class="code-keyword">default</span> store from context
+</span><span class="code-comment">// (ohr:) IMHO I don't think that <span
class="code-keyword">this</span> configuration level is really necessary
+</span>defaultMessageStore(myStore);
+
<span class="code-comment">// 1) Store body.
</span><span class="code-comment">// 2) Set body to <span
class="code-keyword">null</span>.
</span><span class="code-comment">// 3) Set Exchange.CLAIM_CHECK header to
unique claim id.
-</span>from(...).claimCheck().to(...);
+</span>from(...)
+ .claimCheck() <span class="code-comment">// store body in <span
class="code-keyword">default</span> store
+</span> <span class="code-comment">// .claimCheck(header('bigHeader'),
customStore) : store header in custom store
+</span> .to(...);
</pre>
</div></div>
@@ -148,9 +156,18 @@ defaultMessageStore(myStore);
<span class="code-comment">// 1) Lookup <span class="code-keyword">for</span>
the Exchange.CLAIM_CHECK header value.
</span><span class="code-comment">// 2) Read the message.
</span><span class="code-comment">// 3) Set body to the value fetched from the
store.
-</span>from(...).setHeader(Exchange.CLAIM_CHECK, <span
class="code-keyword">const</span>(<span
class="code-quote">"id"</span>)).claim().to(...);
+</span>from(...)
+ <span class="code-comment">// .setHeader(Exchange.CLAIM_CHECK, <span
class="code-keyword">const</span>(<span class="code-quote">"id"</span>)) :
header should still contain the claim id
+</span> .claim() <span class="code-comment">// read body from <span
class="code-keyword">default</span> store
+</span> <span class="code-comment">// .transform(claim()) : more generically
as expression
+</span> <span class="code-comment">// .setHeader('bigHeader',
claim(customStore)) : retrieve from custom store back into original header
+</span> .to(...);
</pre>
-</div></div></div>
+</div></div>
+
+<p>Open issues:</p>
+<ul><li>exception handling if there's no data available for a specific
token</li><li>clean up of stale content that was never claimed
back</li><li>maybe return some kind of DataHandler instead of a token (cf. CXF
MTOM attachments) and retrieve content transparently?</li></ul>
+</div>
</td>
<td valign="top">
<div class="navigation">
![https://cwiki.apache.org/confluence/images/icons/emoticons/warning.gif"](https://cwiki.apache.org/confluence/images/icons/emoticons/warning.gif"){kind=link}
![https://cwiki.apache.org/confluence/images/icons/emoticons/help_16.gif"](https://cwiki.apache.org/confluence/images/icons/emoticons/help_16.gif"){kind=link}