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.
In all cases the session would be quiesced and it would be safe to issue
a session.close().
I do agree that processing prefetched messages is not the ideal
behavior, however it is the only one available if you want to strictly
adhere to AMQP semantics, and I would expect it to also comply with JMS
semantics presuming that you block the session.close() call until
processing of prefetched messages is complete.
--Rafael
