Alan Conway wrote:
I'm teasing out the reliability guarantees offered in different
situations, some things are becoming clear and I want to sound them out.
This stuff would be good in user manual or training material...
The exactly-once guarantee is only valid if and only if neither the
broker nor the client ever crash. By crash I mean a session is
interrupted in a non-orderly fashion and is never successfully resumed.
We will eventually implement the broker half of that guarantee but the
client half is quite heavy going: the client must reliably maintain its
AMQP state persistently or be some kind of cluster in its own right.
Currently this isn't even possible with Qpid as we don't provide access
to the session state in a form that could be used for recovering a
session in a different process.
So if we lower our sights: what guarantees can we offer to
non-bulletproof clients? It turns out the two weaker guarantess
correspond to AMQP protocol options: it would be good to get the spec
clarified a little to make this obvious:
At least once: accept-mode=explicit:
- broker MUST NOT forget a message till it receives an accept from the
client.
- client MUST process the message transfer on receipt and MUST send an
accept only after processing.
- risk: if client A crashes, other clients may receive messages already
processed by A.
At most once: accept-mode=none:
- broker MUST forget messages upon sending the transfer
- client MUST NOT process message on receiving the transfer. It MUST
send an accept and wait for the accept to complete before processing.
- risk: if client A crashes, messages that it has not yet processed may
be lost.
The first case is straightforward in Qpid, but the second case is not.
The trivial implementation (send a synchronous accept for each incoming
message) will perform dreadfully. Is there a case for extending the API
or adding utility classes for this use case? E.g. with a variation of
MessageListener that passes you the messages when accepts complete
rather than when the transfer arrives?
Regarding last paragraph. Can we do something using negative acks
instead? I.e. the client only sends an acknowledgement if it sees that
it has missed a message by using a message sequence number. And asks for
a resend.
William
