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. 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. To me an ack is a lower level concern - did you get the message, not "I can't process the message". RG
