[
https://issues.apache.org/jira/browse/PROTON-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16173947#comment-16173947
]
Alan Conway commented on PROTON-1512:
-------------------------------------
Thinking some more, and I think the original design is correct.
- The AMQP 'aborted' flag on a transfer means throw away *all* data for the
delivery.
- Abort is only useful for multi-frame messages, where part of the message is
already sent.
- We should *never* generate frames with aborted=true and data.
aborted=true *requires* you to ignore the data, so sending both is
meaningless.
I would update proton to enforce this.
- If we receive aborted=true with data from some daft library, we will ignore
the data.
The spec requires us to ignore it so nobody can fault us on that.
What this means for dispatch:
- if we receive an aborted=true frame before we have enough message headers to
forward the message,
we simply ignore the whole delivery like it never happened.
- once we have started forwarding a message, if we get an aborted=true frame,
we forward
an empty aborted=true frame. We're not obliged to forward any data on that
frame since
the aborted=true flag compels the receiver to throw away all the data anyway.
It is quite possible to have proton expose the data (I already did it before I
thought this through) but I believe it is *impossible* do do that *and* have
older
clients correctly raise an error when a message is aborted. Eitehr they will
loop or
stall forever on a delivery wating for data that never comes, or they will
incorrectly
believe the message is completed.
There are 2 different ways that existing bidings and dispatch gather messages,
any way
I try to expose data on an aborted frame will break case A below.
If aborted frames are treated as partial, case A will hang/stall/never finish.
If they are not partial then case A will incorrectly complete the message.
The only way to get all existing clients to fail is to say aborted messages
are not partial and have pn_link_recv return an immediate error.
{code}
/* A: wait for a complete delivery, copy to application */
case PN_DELIVERY: {
if (pn_delivery_readable(d) && !pn_delivery_partial(d)) {
int ret = pn_link_recv(pn_delivery_link(d), buffer,
pn_delivery_pending(d));
if (ret >= 0) {
got_message(buffer, ret);
} else {
error(ret);
}
return COMPLETE_OR_ERROR;
}
break; /* Wait for more PN_DELIVERY events */
}
/* B: Append result of link_recv to app buffer till complete */
case PN_DELIVERY: {
int ret = pn_link_recv(pn_delivery_link(d), buffer+received_so_far,
pn_delivery_pending(d));
if (ret > 0) {
received_so_far += ret;
} else if (ret < 0) {
if (ret == PN_EOS) got_message(buffer, received_so_far);
if (ret < 0) error(ret);
return COMPLETE_OR_ERROR;
}
break; /* Wait for more PN_DELIVERY events */
}
{code}
> 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
