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.
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.
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).
