Alan Conway wrote:
On Tue, 2008-08-19 at 08:20 +0100, Gordon Sim wrote:
I was trying to describe an approach an application might use to get
exactly-once processing guarantees; an accept would be used to prevent
loss of messages, and completion of that accept might need to be tracked
to update the state used to detect duplicates.
I don't think this is possible with unreliable clients and without using
application-specific knowledge to screen duplicates, but I'd love to be
proved wrong again :)
Agreed; that was exactly the case I was referring to.
The problem I see: if you a) process the message before sending accept,
you can get a duplicate as above. If you b) defer processing till after
the accept completes you can lose a message if the client crashes
between sending accept and processing the message. So if you do b) the
client has to be made reliable in some way (logging the message before
sending accept etc.) or if you do a) there has to be some
application-specific way to screen duplicates that might be delivered to
another client/a subsequent incarnation of this client.
Right; in general that might be through a set of sequence numbers for
different publishing streams the application is aware of. Thats easy to
maintain. If however it needs per message state recorded in order to
detect duplicates, then that state needs cleared up and completion of
the accept would be the point at which you could do that. (Not something
I'm suggesting we offer right now though).
