Rafael Schloming wrote:
Gordon Sim wrote:
The only difference between an explicit 'release' and not
acknowledging a message is that the redelivered flag will be set in
the latter case, but not the former.
I don't think this is the only difference. A broker can DLQ unacked
messages, but not released messages.
What are the rules around that? I would expect unacked messages to be
left on the queue, as the delivery hasn't succeeded. DLQing them seems
quite wrong to me. Certainly neither of the qpid brokers do that.
As the ack is a key reliability mechanism, allowing arbitrary DLQ
decisions based on unacked deliveries seems to me to undermine the
ack-based reliability model.
[...]
In the case of the no-ack mode, the whole aim is to allow optimisation
of the case where redelivery is not required (e.g. often where a
client has its own exclusive queue representing a subscription).
That's a good point. Releasing prefetched messages in no-ack mode won't
actually do anything since they may have already been discarded. Given
that I would fall back to processing all prefetched messages in the case
of no-ack and letting the user choose to throw them away if that is
appropriate for the application.
I think by closing the session the application is saying it wants to
quit. Perhaps the close on the MessageConsumer could do something like
this... i.e. don't return from that close until all the messages have
been pumped through the listener?
