The test case basically does the following.
It tries to receive 100 messages. But every 5th message, it checks to see if it's marked redelivered. If not it will call recover().
Once issues identified in QPID-3602 &
QPID-3629 is fixed, the correct behaviour should be as follows.
1. We should receive 100 messages.
2. We should see 20 messages marked as redelivered.
3. At at point we should not see the number of messages in our prefetch exceeding the value specified with max_prefetch (or capacity using addressing).
Currently with some of the patches for QPID-3602,
QPID-3629 and a patch for this issue, I see the following.
1. We receive 100 messages (this was never a problem)
2. We now receive 24 messages marked as "redelivered" (consistently) no matter what the prefetch count is. Before the patches for these issues, the number of redelivered messages depended on the prefetch, partly due to the client prefetching more than it needed, the broker sending more than the client needed and the client marking everything in it' prefetch buffer as "redelivered".
3. With the fix for
QPID-3629 we now see that the messages in the clients prefetch buffer does not exceed the max_prefetch value at any time. (However prefetch=0 case does not work, and I attribute that to client error at this point). But there seems to be another issue with the said patch. At this point not sure if it's client or broker side. Since this issue does not arise without the patch for QPID-3629 it's reasonable to assume that it's caused by this patch.