<div class="gmail_quote">On Sat, Aug 7, 2010 at 13:50, Matthew Sackman <span dir="ltr">&lt;<a href="mailto:matthew@rabbitmq.com">matthew@rabbitmq.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Aug 06, 2010 at 10:43:56PM +0100, Tim Fox wrote:<br>
&gt; The way we do it in HornetQ is we have a well defined header key<br>
&gt; &quot;_HQ_DUP_ID&quot;. The client can set this with some unique value of it&#39;s<br>
&gt; choice before sending (e.g. a GUID). When the server receives the<br>
&gt; message if the _HQ_DUP_ID header is set, it looks up the value in<br>
&gt; it&#39;s cache, and if it&#39;s seen it before it ignores it. The cache can<br>
&gt; optionally be persisted.<br>
<br>
</div>How do you prevent the cache from growing without bound?<br>
<font color="#888888"><br>
Matthew<br>
</font><div><div></div><div class="h5"><br></div></div></blockquote></div>That&#39;s really like the piece of string question, no? Of course it can fill up, as can the DB where things are persisted for those cases where messages cannot be delivered.<div>
Having an unique ID in every message is not something new and not restricted to messaging, of course. It is simply a very good idea!</div><div>TCP/IP claims to be a &#39;reliable&#39; transport...The problem with that is that packets get &#39;lost&#39; or &#39;dropped&#39; or simply die of &#39;old age&#39;. Similar, but more complex, problems exist with queuing.</div>
<div>What has not been touched on in this little discussion so far is the question of transactions, and I do not mean those in the 0.9.1 spec, but those described in the 1.0 spec. Here again, JMS is leading the way with something which in my mind is as necessary as guaranteed once (or at least once). Updating DBs from queues and posting the results of those updates to queues should be atomic; and if I want my debit/credit to happen once rather than many times or not at all, then a combination of transactions and guaranteed delivery becomes very attractive both to the designer and the developers. Yes, ACID comes to mind here...and it is indeed what I am referring to.</div>
<div><br clear="all">It is great to participate in conversations of this nature - thank you for putting up with my sometimes oblique ramblings:-)<br>�<br>---<br>John Apps<br>(49) 171 869 1813<br>
</div>