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

Rafael H. Schloming commented on PROTON-401:
--------------------------------------------

After looking at the proposed patch and tests, I believe that this isn't really 
a bug but rather a missunderstanding of how the API is supposed to behave. The 
patch is effectively modifying the engine to remember that the application 
previously indicated that it was drained.This will, however, introduce race 
conditions since the engine can't actually know if the application is currently 
drained or simply was drained at some point in the past.

To understand the semantics, it helps to imagine an application that has 
implemented a message queue exposed via AMQP at both ends, with strict 
semantics regarding "emptiness".  In such a scenario, you should be able to 
push a message onto the tail of the queue, verify that it is accepted, and then 
drain from the head of the queue and be guaranteed of receiving at least one 
message. With this patch you would no longer have that guarantee. You would 
have a race condition where the engine remembers the queue used to be empty and 
drains the credit even though there is a message to supply.

I believe the fix for the scenario is for the application to call drained more 
frequently, i.e. whenever it wakes up and there is positive credit on the link 
and no messages to send.

> Ordering issue prevents credit drain from working properly
> ----------------------------------------------------------
>
>                 Key: PROTON-401
>                 URL: https://issues.apache.org/jira/browse/PROTON-401
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: 0.4
>            Reporter: Ken Giusti
>            Assignee: Ken Giusti
>         Attachments: drain-error.patch, drain-hack.patch
>
>
> If the sending link calls pn_link_drained() to indicate that it has send all 
> pending data, and afterwards it receives a Flow frame with drain=true from 
> the peer, then the drain never completes.
> The ordering is the problem: if the flow frame w/drain=true is received 
> _BEFORE_ the sender calls pn_link_drained(), then it works.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to