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

ASF subversion and git services commented on PROTON-1512:
---------------------------------------------------------

Commit 6743ab4418736dab353b8566dae7d94fd2e34f2b in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6743ab4 ]

PROTON-1512: Fixes and doc clarifications for pn_delivery_aborted()

- added explict PN_ABORTED error code (PN_STATE_ERR has another meaning in this 
context)
- fixed initialization bug for aborted flag
- enforce discarding all data for aborted frames on sender and receiver, for 
interop sanity
- clarified docs - see below

Goal is to enable *correct* use of abort while minimizing interop problems with 
existing
abort-unaware proton code (and other AMQP clients)

The only correct use of abort is when part of a message has already been
sent. In a router, an incoming message can be aborted before any of it has been
forwarded, or even before enough headers have been acquired to know how to
forward it. Such messages should simply not be forwarded at all. Dispatch
doesn't (shouldn't) promise frame-by-frame identity for message routing so
silently dropping an early-aborted message is entirely valid and
unavoidable. Using abort is only valid when part of a message has already been
forwarded.

Here's the explanation of the backwards-compatibility problem:

/**
 * Check if a received delivery has been aborted.
 *
 * An aborted delivery means the sender cannot complete the message and the
 * receiver should discard any data already received. There is nothing further
 * to be done with the delivery: it is pn_delivery_settled() and pn_link_recv()
 * returns ::PN_ABORTED.
 *
 * For backward compatibility with code that does not check 
pn_delivery_aborted(),
 * the following are true of an aborted delivery:
 *
 * - pn_delivery_partial() is false - old code will not wait forever for more 
data
 *
 * - pn_delivery_pending() returns 1, not 0 - old code that checks for 
completion with
 *
 *       if (pn_delivery_pending(d)==0 && !pn_delivery_partial(d))
 *
 *   will not mistake this for successful completion, and will call 
pn_link_recv()
 *
 * - pn_link_recv() returns ::PN_ABORTED - old code will know there is some 
kind of error.
 *
 * @see pn_delivery_abort()
 * @param[in] delivery a delivery object
 * @return true if the delivery has been aborted, false otherwise
 */
PN_EXTERN bool pn_delivery_aborted(pn_delivery_t *delivery);


> Expose the "aborted" flag for transferred deliveries
> ----------------------------------------------------
>
>                 Key: PROTON-1512
>                 URL: https://issues.apache.org/jira/browse/PROTON-1512
>             Project: Qpid Proton
>          Issue Type: New Feature
>          Components: proton-c
>            Reporter: Ted Ross
>            Assignee: Alan Conway
>              Labels: api
>             Fix For: proton-c-0.18.0
>
>
> As we develop support for message streaming in Qpid Dispatch Router (i.e. 
> frames for large multi-frame messages are forwarded to destinations as they 
> arrive, before the complete message is received), there is a need to handle 
> the case where a received message is never completed.
> The AMQP protocol has a provision for this in the "aborted" flag in the 
> transfer performative.  If the router is in the process of streaming a large 
> message from sender to receiver and the sender drops before completing the 
> delivery, the router can send a transfer to the downstream receivers with the 
> "aborted" flag set.  This would indicate that the message should not be 
> processed and would not cause any framing errors on the link.
> Proton does not currently expose this capability in its API (There is a 
> pn_link_abort in the C header file, but it is commented out and not 
> implemented).
> In order to properly handle the failure cases for message streaming, this 
> feature must be usable in Proton.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Reply via email to