[rabbitmq-discuss] State and idempotency (was Re: Replicated message queue? DRDB+Hearbeat?)

[Tony Garnock-Jones]

Tom Samplonius wrote:
>> application logic to identify duplicate messages (just in case).
> 
> I've never come across a good way of doing this.  I can attach a
> unique id to each message, but then the clients have to keep state on
> which ids they've processed.  And if you multiple clients, they need
> to talk to each other too.  I don't want consumers to have to keep
> state.

Indeed. Ultimately, to support exactly-once delivery, the clients do 
have to have some kind of state. It can be reduced to a minimum, though 
- perhaps as far as two facts: the client's name, and a single integer 
representing its "high tide mark" in the incoming message stream.

The way we're looking to address this is to introduce the notion of a 
session. Sessions provide a notion of scope for stateful things like 
exactly-once delivery, with minimal client-side state.

By using the client-to-server notion of sessions, each client just needs 
to remember where it was up to in its conversation with the server, 
rather than anything about the wider conversations with other clients 
that are layered on top of the AMQP network, reducing the O(n^2) problem 
to O(n).

Regards,
   Tony