[jira] [Commented] (PROTON-1514) [proton-c] When last frame of multi-frame transfer has settled=true, Proton still considers delivery as unsettled

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

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

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

Commit 2dda72c703e1a2bffac1bbcd509205e5645c77d9 in qpid-proton's branch refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2dda72c ]

PROTON-1514: check for settled flag on all frames of multi-frame transfer;
enforce sole legal transition is settled to unsettled.
The previous revert at 6e15ddc was a false alarm.


> [proton-c] When last frame of multi-frame transfer has settled=true, Proton still considers delivery as unsettled
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: PROTON-1514
>                 URL: https://issues.apache.org/jira/browse/PROTON-1514
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: proton-c-0.17.0
>            Reporter: Ganesh Murthy
>            Assignee: Cliff Jansen
>            Priority: Major
>              Labels: framing
>             Fix For: proton-c-0.23.0
>
>
> I have a situation where a receiver (proton python's simple_recv.py) is receiving a multi-frame transfer from a Dispatch Router. The settled flag is false on all the transfer frames except on the last frame which has settled=true as seen here -
> {noformat}
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0, settled=false, more=true] (16351) "g here33227Long string here33228Long string here33229Long string here33230Long string here33231Long string here33232Long string here33233Long string here33234Long string here33235Long string here33236Long string here33237Long string here33238Long string here33239Long string here33240Long string here33241Long string here33242Long string here33243Long string here33244Long string here33245Long string here33246Long string here33247Long string here33248Long string here33249Long string here33250Long string here33251Long string here33252Long string here33253Long string here33254Long string here33255Long string here33256Long string here33257Long string here33258Long string here33259Long string here33260Long string here33261Long string here33262Long string here33263Long string here33264Long string here33265Long string here33266Long string here33267Long string here33268Long string here33269Long string here33270Long string here33271Long string here33272Long string here33273Long string here33274Long string here33275Lon"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0, settled=false, more=true] (49053) "ng string here34006Long string here34007Long string here34008Long string here34009Long string here34010Long string here34011Long string here34012Long string here34013Long string here34014Long string here34015Long string here34016Long string here34017Long string here34018Long string here34019Long string here34020Long string here34021Long string here34022Long string here34023Long string here34024Long string here34025Long string here34026Long string here34027Long string here34028Long string here34029Long string here34030Long string here34031Long string here34032Long string here34033Long string here34034Long string here34035Long string here34036Long string here34037Long string here34038Long string here34039Long string here34040Long string here34041Long string here34042Long string here34043Long string here34044Long string here34045Long string here34046Long string here34047Long string here34048Long string here34049Long string here34050Long string here34051Long string here34052Long string here34053Long string here"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0, settled=false, more=true] (98106) "1Long string here36342Long string here36343Long string here36344Long string here36345Long string here36346Long string here36347Long string here36348Long string here36349Long string here36350Long string here36351Long string here36352Long string here36353Long string here36354Long string here36355Long string here36356Long string here36357Long string here36358Long string here36359Long string here36360Long string here36361Long string here36362Long string here36363Long string here36364Long string here36365Long string here36366Long string here36367Long string here36368Long string here36369Long string here36370Long string here36371Long string here36372Long string here36373Long string here36374Long string here36375Long string here36376Long string here36377Long string here36378Long string here36379Long string here36380Long string here36381Long string here36382Long string here36383Long string here36384Long string here36385Long string here36386Long string here36387Long string here36388Long string here36389Long string h"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0, settled=false, more=true] (130808) "re41013Long string here41014Long string here41015Long string here41016Long string here41017Long string here41018Long string here41019Long string here41020Long string here41021Long string here41022Long string here41023Long string here41024Long string here41025Long string here41026Long string here41027Long string here41028Long string here41029Long string here41030Long string here41031Long string here41032Long string here41033Long string here41034Long string here41035Long string here41036Long string here41037Long string here41038Long string here41039Long string here41040Long string here41041Long string here41042Long string here41043Long string here41044Long string here41045Long string here41046Long string here41047Long string here41048Long string here41049Long string here41050Long string here41051Long string here41052Long string here41053Long string here41054Long string here41055Long string here41056Long string here41057Long string here41058Long string here41059Long string here41060Long string here41061Long st"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0, settled=true, more=false] (57905) "ere47242Long string here47243Long string here47244Long string here47245Long string here47246Long string here47247Long string here47248Long string here47249Long string here47250Long string here47251Long string here47252Long string here47253Long string here47254Long string here47255Long string here47256Long string here47257Long string here47258Long string here47259Long string here47260Long string here47261Long string here47262Long string here47263Long string here47264Long string here47265Long string here47266Long string here47267Long string here47268Long string here47269Long string here47270Long string here47271Long string here47272Long string here47273Long string here47274Long string here47275Long string here47276Long string here47277Long string here47278Long string here47279Long string here47280Long string here47281Long string here47282Long string here47283Long string here47284Long string here47285Long string here47286Long string here47287Long string here47288Long string here47289Long string here47290Long s"... (truncated)
> {noformat}
> Proton considers the delivery as unsettled and as a result some of the Dispatch router tests are failing like this one - https://github.com/apache/qpid-dispatch/blob/master/tests/system_tests_one_router.py#L1097
> The AMQP 1.0 spec says the following about the settled flag on transfers -
> settled - If not set on the first (or only) transfer for a (multi-transfer) delivery, then the settled flag MUST be interpreted as being false. For subsequent transfers in a multi-transfer delivery if the settled flag is left unset then it MUST be interpreted as true if and only if the value of the settled flag on any of the preceding transfers was true; if no preceding transfer was sent with settled being true then the value when unset MUST be taken as false.
> My question is, is this delivery settled? It logically looks settled to me since the last frame did have settled=true.
> According to rgodfrey - 
> I agree the spec is horribly unclear on this point.
> I wish we had said something along the lines of two transfers in a
> multi-transfer delivery must either both have the same value for settled,
> or one must be unset (i.e. you can't have frames for the same transfer
> saying both settled and not settled).  Given the spec does not say this
> then I think we have to treat the case you describe as meaning that the
> delivery should be considered settled (and the Proton is behaving
> incorrectly by the sounds of it).  This interpretation is also reasonable
> in the face of the definition of other fields on transfer such as "state".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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