[
https://issues.apache.org/jira/browse/PROTON-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-1514.
----------------------------------
Resolution: Fixed
> [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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
