You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by bu...@apache.org on 2013/02/22 22:18:13 UTC

svn commit: r851582 - in /websites/production/camel/content: cache/main.pageCache camel-30-message-store.html

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">