The Pre0_10CreditManager mishandles message credit. In some circumstances allows message credit to fall beneath 0. Once this has occurred, messages cease to flow to all consumers associated with the session (messages appear stuck on the queue). Recreating the session (or connection) will allow messages to flow again. This problem was reproduced on a 0.32 derivative but it appears the same issue will affect newer releases too.
New analysis has shown that the client starvation on 0.32 was fixed by
QPID-6797. The issue was that the ConsumerTarget_0_8#_entryReleaseListener StateChangeListener removed itself unconditionally even in the case where a different state change happend. This meant that the credit would not be restored leading to wrong accounting in Pre0_10CreditManager.
Furthermore, the message credit potentially going negative in the case where the credit limit is lowered by a basic_qos is expected and acceptable behaviour because the client does still have the messages associated with that credit prefetched. After those prefetched messages are acknowledged the credit will become positive again.
However there are credit account issues in Pre0_10CreditManager.
- The Manager should keep track of the credit even if the limit is unlimited (i.e. 0) because at a later point the limit might change through a basic_qos at which point we need to know the accurate credit state
- useCreditForMessage does not handle negative credit correctly.