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? In fact now that I look at what I've written I am shocked we do (2). It seems very wrong to me. RG
