qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-7387) [Java Broker, AMQP 0-8..0-91] Correct handling of consumer credit
Date Thu, 08 Sep 2016 14:17:21 GMT

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

ASF subversion and git services commented on QPID-7387:

Commit 1759830 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1759830 ]

QPID-7387: [Java Broker] 0-8..0-91 Correct handling of consumer credit

> [Java Broker, AMQP 0-8..0-91] Correct handling of consumer credit
> -----------------------------------------------------------------
>                 Key: QPID-7387
>                 URL: https://issues.apache.org/jira/browse/QPID-7387
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: 0.32, qpid-java-6.0, qpid-java-6.1
>            Reporter: Keith Wall
>             Fix For: qpid-java-6.1
>         Attachments: WIP_Prevent0-9CreditManagerGoingNegative.patch, WIP_Python0-91PrefetchTest.patch
> -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.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message