[
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)