qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: Unacknowledged messages arrive after new messages when recreating a durable subscriber.
Date Thu, 08 Mar 2007 08:43:44 GMT
On 07/03/07, Gordon Sim <gsim@redhat.com> wrote:
> Gordon Sim wrote:
> > Currently, messages are taken off the queue when sent to consumers then
> > requeued again (at the end of the queue) if the client fails to
> > acknowledge them, so yes it is expected in one sense.
>
> Just a quick update on this: I answered based on old knowledge of the
> codebase and gave an incorrect answer as a result - apologies!
>
> On a quick inspection of the latest code it appears that this issue has
> been at least considered as of rev 510897. As that seems to be later
> than the version you are running it appears it may not be working as
> expected. Martin, I believe you addressed this issue? If so you are
> probably in a better position to comment on the issue as raised?

The JMS Spec 4.4.11 says:
"A session's recover method is used to stop a session and restart it
with its first
unacknowledged message. In effect, the session's series of delivered messages
is reset to the point after its last acknowledged message. The messages it now
delivers may be different from those that were originally delivered due to
message expiration and the arrival of higher-priority messages.
A session must set the redelivered flag of messages it redelivers due to a
recovery."

Which would mean that the ordering 4,5,3 may be within the bounds of
JMS. However, if you had sent 5000 messages message 3 would arrive
after those 5000 as this is the default prefetch count in qpid. This
isn't ideal so the current head of qpid now flushes all the messages
from the client and requests new messages. Those messages that have
been flushed return to the front of the queue. However when priority
queues and message expiration are implemented the ordering will
reflect those values.

-- 
Martin Ritchie

Mime
View raw message