Robert Greig wrote:
On 25/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote:
It's not arbitrary. An ack informs you that a message has been
processed, but you can't infer one way or another from the absence of an
ack, therefore you *have* to deal with the possibility that these
messages have been processed already regardless of whether you do it by
setting the redelivered flag or by DLQing the message. Either way I
don't think it's acceptable for a routine close of a consumer to cause
redelivery of a slew of messages that may already have been processed.
It would, for example, be unacceptable to any application that requires
human intervention to deal with redelivered messages.
I think it is wrong to say you can DLQ a message because you have not
received an ack. A DLQ is for cases where the client has rejected a
message explicitly or you cannot deliver a message.
That's not what I said. What I said was the broker must have the option
to DLQ a message if the client repeatedly terminates without
acknowledging or releasing the message. This is something that could
easily happen if normal termination results in unacked messages the same
way crashing does.
In other words what I'm saying is that it is a bad thing if the broker
cant tell the difference between normal termination and a crash.
DLQing a message because of lack of ack hugely complicates recovery
from the application's perspective. Consider the case of an app that
crashes for some reason during processing and does not send an ack for
a message.
If that message were DLQ'd then what would the app do upon startup? It
would have to know to check a DLQ for messages before consuming from
the normal queue, or it would require operator intervention to move
the messages from the DLQ back onto the normal queue. Certainly in the
environment that I work in, that would be unacceptable to most
applications since it would lengthen and complicate the recovery
process hugely.
How exactly an application wants to deal with recover probably depends
on the application. For some it may be more convenient for messages to
be on the same queue with a flag set, for others it may be more
convenient to automatically route them to a different queue. I don't
think the difference is material to my argument.
To me an ack is a lower level concern - did you get the message, not
"I can't process the message".
I'm not sure I understand this. A message level ack means that the
message was processed, not that the message was received. Repeated
crashing of a client is what means "I can't process the message."
--Rafael
