[ 
https://issues.apache.org/jira/browse/PROTON-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056354#comment-15056354
 ] 

Robbie Gemmell commented on PROTON-1077:
----------------------------------------

This occurs because proton-j copies the remote link credit value into its local 
transport receiver state whenever the sender sends a flow that advances the 
delivery count.

The only typical case where proton based senders send flows to the receiver is 
when the reciever drains credit and the sender has insufficient messages to 
consume all the credit and must send a 'drain response' flow as well, in which 
case credit will be 0 and this is the goal. No issue noticed.

The java broker sends recivers flows in additional situations, and sent flows 
with link credit of 0 that also appeared (QPID-6947) to advance the delivery 
count by a small amount while the client was not requesting a drain (after 
having previously done so), followed by a flow that then had non-zero 
link-credit reflective of the clients previous credit top up, but not advancing 
the delivery count meaning proton-j did not copy the updated remote link-credit 
value into its local transport state as it had before, making the link state 
and transport state inconsistent. This was followed by messages from the broker 
using the available credit, which would then make the transport state 
incorrectly go negative as it was decremented.

Proposed change is to make the transport state be adjusted by the delivery 
count delta the same way the link state is, keeping the amount they are 
adjusted by consistent, and ensuring the remote link credit value doesnt 
overwrite the local state value which is keeping track of the consumers view of 
the credit, which is authoratative. This appears to be what proton-c does in 
this area.
{noformat}
+++ 
b/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportReceiver.java
@@ -48,7 +48,7 @@ class TransportReceiver extends TransportLink<ReceiverImpl>
         if(delta > 0)
         {
             getLink().addCredit(-delta);
-            setLinkCredit(getRemoteLinkCredit());
+            addCredit(-delta);
             setDeliveryCount(getRemoteDeliveryCount());
             getLink().setDrained(getLink().getDrained() + delta);
         }
{noformat}

> receiver link and transport view of credit can become disjoint when sending 
> link sends flow frames
> --------------------------------------------------------------------------------------------------
>
>                 Key: PROTON-1077
>                 URL: https://issues.apache.org/jira/browse/PROTON-1077
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-j
>    Affects Versions: 0.11
>            Reporter: Robbie Gemmell
>
> If a recieving link receives flow frames from the sending peer updating 
> advancing the delivery count [and setting credit to 0], then recieves flow 
> frames from the sender updating credit but not advancing the delivery count, 
> then receives messages, the Link and TransportLink views of the credit can 
> become disjoint, leading applications to think they have a different amount 
> of credit than they actually do, and leading to a different amount of new 
> credit being flowed to the sender than expected, even none.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to