Robert Greig wrote:
On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote:
Strictly speaking I think you do need to send a basic.cancel. Without
sending a basic.cancel and getting confirmation that the cancel is
complete the broker will still be attempting to transmit messages to a
client when the close occurs. If this happens when there is active
message flow then there will pending messages when the close occurs and
depending on how a broker behaves, this could cause messages to be
unnecessarily DLQed, or unnecessarily lost in the case of no-ack.
Hmm. There is no DLQ though? Also if you have no-ack there is risk of
message loss built into that?
The java broker may not have a DLQ, but any broker being conservative
about exactly once semantics will need to have a DLQ for messages that
may have been processed by a client. Messages sent on a connection that
was aborted would fall into this category.
As for no-ack, there is a big difference between losing messages when
the network dies, and losing messages whenever you close a connection.
There are many applications that can tolerate the former, but not the
latter.
My logic was that it *must* work when you ctrl-C or kill -9 the client.
There is a difference between a clean shutdown and an abort. A clean
shutdown will always involve some sort of handshake. So while you
definitely want to be as graceful as possible in the case of an abort,
there will fundamentally be unresolved state without the handshake, and
many applications will not be able to tolerate that unresolved state.
--Rafael
