On Wed, 2008-06-04 at 10:15 -0700, TLFox wrote: > > > Arnaud Simon wrote: > > > > > > 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. > > > > I believe that passage is really referring to the "weird" jms inconsistency > where the the message is not acked until after onMessage() has finished > executing in the case of a MesssageListener with AUTO_ACKNOWLEDGE. > > But even if it also applies to receive(), then to ensure this statement: > > "Only a session’s last > consumed message is subject to this ambiguity" > > You would still have to ack synchronously in order to guarantee that only > the last message might get redelivered. If you acked async you might get N > messages redelivered where N can be > 1, depending on how long it takes for > the async ack to get to the server and the rate of consumption. > > Interesting discussion though.
If it also applies to receive(), and that's my interpretation, we can ack pseudo-asynchronously i.e. the next message transfer could carry an ack flag confirming that the broker has received the previous message acknowledgment. So we don't have to block on the ack before delivering the message to the receiver. Note that when the client lib is pre-fetching messages we only need to deliver the next message after the sync ack of the previous message has returned. Arnaud
