[rabbitmq-discuss] State and idempotency (was Re: Replicated message queue? DRDB+Hearbeat?)
tonyg at lshift.net
Thu Feb 28 08:25:31 GMT 2008
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
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
More information about the rabbitmq-discuss