Robert Greig wrote:
On 25/09/2007, Gordon Sim <[EMAIL PROTECTED]> wrote:
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?
I agree. Currently if I understand the code correctly (Martin correct
me if I am wrong) a close() on the message consumer will reject all
prefetched messages. We could perhaps have some extended JMS methods
on the consumer to:
1) closeImmediately (maybe closeJFDI() :-))
2) closeRejecting (current behaviour)
3) closeAfterProcessing - close after processing any prefetched messages
I personally think that the default close() should be (1) and that
closing a session should do (1) on any unclosed consumers.
The JMS semantics are pretty clear. Close at the consumer or session
level is supposed to block until any in-progress message listeners are
finished. If there are prefetched messages remaining after the
in-progress listeners are finished, they either need to be returned to
the server (i.e. option 2 except without abusing reject), or processed
(option 3).
Option 3 seems like a reasonable extension of JMS semantics in the
presence of prefetch. Option 2 (without abusing reject) seems the most
correct. I'm not sure why you'd ever want to do option (1). It is
basically the same as option (2) except any messages prefetched for that
consumer are now stranded for the duration of the session. This doesn't
seem very friendly, and certainly wouldn't be a good default.
--Rafael
