[ 
https://issues.apache.org/jira/browse/QPID-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721185#action_12721185
 ] 

Rob Godfrey commented on QPID-1621:
-----------------------------------

The attached test is (I believe) incorrect.

For a start the assumption that low watermark = high watermark / 2 doesn't 
hold... 

By default getPrefetchLow() == getPrefetchHigh()

[Incidentally - outside of the NOACK mode there is no concept of 
watermarking... there is a single prefetch number sent in a BasicQos method]

Thus the test actually tries to take max_prefetch + 1 messages before commiting.

In this case the last attempted receive in the first loop timesout and you get 
back a null.

The fact the message is null then means the second loop is essentially skipped.

Looking at the log output for the test it is clear that after the commit, the 
broker sends all the messages to the broker.

Fixing the test so that the first loop attempts to receive < than the prefetch 
value results in the test passing.


> Flow control fails to release credit when unacknowledge message count exceeds 
> the low water mark
> ------------------------------------------------------------------------------------------------
>
>                 Key: QPID-1621
>                 URL: https://issues.apache.org/jira/browse/QPID-1621
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: M3, M4, 0.5
>            Reporter: Marnie McCormack
>            Assignee: Aidan Skinner
>         Attachments: 
> 0001-QPID-1621-add-testHighLowStarvation-to-test-this-is.patch
>
>
> Summary: 
> If we receive more than 2500 msgs on a transacted session then we cannot 
> recover that credit and will block at the prefetch limit of 5000. 
> Acknowledging at msg 2501 demonstrates this issue (of being limited to 5000 
> mgs) but at <2500 then we are able to receive as many messages as are 
> available, beyond 5000. 
> This issue has been seen on Qpid M3, further extraction of a test case and 
> testing on M4 is required. 
> The test should also adjust the low water mark to identify if that is part of 
> the issue. 
> Workaround: 
> To prevent client starvation ensure that clients never have more than the low 
> water mark (2500 default) of unacked messages. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Reply via email to