2008/6/4 Arnaud Simon <[EMAIL PROTECTED]>: > > On Wed, 2008-06-04 at 02:37 -0700, TLFox wrote: >> >> >> Rafael Schloming wrote: >> > >> > >> > The JMS spec isn't fully consistent on this point. It clearly states >> > that with AUTO_ACKNOWLEDGE acks are sent *after* the message listener is >> > invoked, so (with listeners at least) this window will always exist even >> > if you sync the acks. >> > >> >> Yes indeed. This is a known glaring inconsistency in the spec. >> >> >> >> > With receive() of course the ack happens before the application sees the >> > message, so you could avoid the window by syncing there, however I don't >> > know offhand of anything that directly states that should be the case. >> > > The JMS spec says: > "When a client uses the AUTO_ACKNOWLEDGE mode, it is not in direct > control of message acknowledgment. Since such clients cannot know for > certain if a particular message has been acknowledged, they must be > prepared for redelivery of the last consumed message. This can be caused > by the client completing its work just prior to a failure that prevents > the message acknowledgment from occurring. Only a session's last > consumed message is subject to this ambiguity" > > That makes me think that we may not need to sync.
It makes me think that we need to ensure the ack has been processed on the broker *before* delivering the next message to onMessage. Otherwise there will be ambiguity about more than one message which isn't allowed by the above text. Sounds like a sync is required. Martin >> JMS spec is explicit in that it requires "at most once" semantics in this >> case, this surely implies you must sync the ack before returning from >> receive(). >> >> How else would you guarantee those semantics without syncing? >> > > -- Martin Ritchie
