On Tue, 2008-08-19 at 08:20 +0100, Gordon Sim wrote: > Then I am confused: above I thought we had now agreed that at-most-once > guarantees could be obtained by not requiring an accept at all? Yes I have been confusing the issue by mixing singleton and cluster problems in my mind. Let me try to get this straight, from the clients perspective where we treat the broker as a singleton, no cluster issues:
at-most-once: use accept-mode=none, broker forgets message as soon as it is sent, client processes message as soon as it is received. No accepts. Messages can be lost if the client crashes. Easy. at-least-once: use accept-mode=explicit. Client processes message immediately and then sends accept. Message can be double-processed if client crashes before sending accept. So you're right Gordon, both of these cases can be handled in a straightforward way with the existing API. > 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 :) 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.
