[rabbitmq-discuss] Exactly Once Delivery

[John Apps]

On Sat, Aug 7, 2010 at 13:50, Matthew Sackman <matthew at rabbitmq.com> wrote:

> On Fri, Aug 06, 2010 at 10:43:56PM +0100, Tim Fox wrote:
> > The way we do it in HornetQ is we have a well defined header key
> > "_HQ_DUP_ID". The client can set this with some unique value of it's
> > choice before sending (e.g. a GUID). When the server receives the
> > message if the _HQ_DUP_ID header is set, it looks up the value in
> > it's cache, and if it's seen it before it ignores it. The cache can
> > optionally be persisted.
>
> How do you prevent the cache from growing without bound?
>
> Matthew
>
> That'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.
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!
TCP/IP claims to be a 'reliable' transport...The problem with that is that
packets get 'lost' or 'dropped' or simply die of 'old age'. Similar, but
more complex, problems exist with queuing.
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.

It is great to participate in conversations of this nature - thank you for
putting up with my sometimes oblique ramblings:-)

---
John Apps
(49) 171 869 1813
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100807/82c2cefc/attachment.htm>