Gordon Sim wrote:
Rafael Schloming wrote:
Robert Greig wrote:
On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote:
That's true, however I would think that the expected JMS behavior would
be for connection close to do a clean shutdown.
OK. Note that this is Session.close() so it will close the channel.
Apart from processing all prefetched messages (which I think it's
arguable is not what someone doing a close on a session would want),
what do you think a clean shutdown of a consumer would involve?
For 0-10 I would issue a message.cancel for all subscriptions, and do
an execution.sync to confirm that they are all complete. At that point
I know that no more messages will be arriving and then I would issue a
message.release for all the prefetched messages.
For 0-8 I would do something similar. Issue a synchronous basic.cancel
for each subscription. When they are all complete, for strict AMQP
mode I would then process all the prefetched messages, and for non
strict AMQP mode I would add the release method from 0-10 and use that
to release prefetched messages.
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.
In each case message ordering may be lost if there are other active
consumers on the same queue. At present the redelivered flag (which is a
warning that the message *may* have been delivered once already, not a
statement that it has) signals this, there isn't yet an equivalent to
indicate potential loss of order due to release (though that will
hopefully come).
While I think the addition of the release method is valuable, I see no
real benefit in trying to retrofit it into older implementations.
It may not be worthwhile for this case alone, however the Java client
implementation currently uses reject in a variety of ways, and the
intent is almost always to do a release, not an actual reject.
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.
--Rafael
