Robert Greig wrote:
On 25/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote:
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).
Does the JMS spec have any concept of prefetch? I will have to check.
In progress message listeners to me means processing of a single
message.
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.
I think 1 and 2 are different. To me, 1 would be the same as the
ctrl-c behaviour i.e. there would be no acks so the messages would be
requeued. 2 is the client saying "I don't want these messages".
Ironically, I would say that 2 is the one I would probably never want
to use since I would probably only want to reject messages I have had
a look at.
I am not sure what you mean by "stranded for the duration of the
session". The messages would be requeued and if there was another
consumer they would be delivered to that consumer, no?
They can't be requeued if the client can still process them.
In fact now that I look at what I've written I am shocked we do (2).
It seems very wrong to me.
By option 2 (without abusing reject) I meant releasing the messages,
i.e. sending an indicator to the broker that I'm never going to ack,
reject, or process the given messages and it is safe to deliver them to
any client without indicating that they may already have been processed.
This is actually fairly close to how the java broker interprets reject,
even though it is not compliant with the spec definition of reject.
--Rafael
