I don't get error on ack at all. If I receive an
acknowledgment message, and for whatever reason cannot
process it (let's say it was mangled in transit)
then I'll simply resend the original message
until I get an ack, or until either the message's TTL
expires or the retries have been exhausted at which
time I'll notify the application that I have not
received an acknowledgment confirming the message's
receipt by the intended recipient.
As for ack on error, why on earth cannot an error
be treated with all of the same QoS as a normal
message?!?!? What if the recipient wants to be sure that
the original sender is notified that there has been
a problem in processing the message? Seems perfectly
reasonable to me to allow this.
The circularity comes only (IMO) when you error on
an acknowledgment because this would require that
the sender of the acknowledgment provide for the
ability to process the error (as well as for specification
as to what processing is required which is currently
not addressed in the specification).
IMO, the only thing that the spec should say is that
an ack cannot be requested for an acknowledgment message.
Cheers,
Chris
Cliff Collins wrote:
> I like Error on Ack (like the 1.0 model) the best.
>
> If we allow Ack on Error then it becomes really messy when there is a
> failure on the Ack message. And when the retries are reached on sending an
> "error" over RM does this generate another error of delivery failure? Messy
> :-)
>
>
>>