[ https://issues.apache.org/jira/browse/PROTON-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855513#comment-16855513 ]
Robbie Gemmell commented on PROTON-2056: ---------------------------------------- {quote}This does leave open the explanation for the sender side disposition in Ganesh Murthy's trace in https://issues.apache.org/jira/browse/PROTON-2056?focusedCommentId=16852243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16852243. {quote} Ganesh later noted he applied the patch to the wrong checkout/install originally, so are those traces not just reflective of the original bug? https://issues.apache.org/jira/browse/PROTON-2056?focusedCommentId=16852374&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16852374 I expect the buggy behaviour likely differs (on the wire) based on whether the two dispositions are processed from the same read, in that if they were it would already know it is remotely-settled before actually processing the release, and might behave differently. If they arrive in the same read, I might expect no settled disposition would get sent to the receiver in that case even though the sender erroneously locally settles, because the transport knows its already remotely-settled. I'd expect that the local settlement could (I haven't verified) also prevent the on_settled callback actually firing for the second disposition even though it was already read. It certainly should stop it firing in my mind, per earlier comments, since the delivery was locally settled by the point it could. Alternatively, if they arrived in different reads, processing the release could actually cause it to send a settled disposition to the receiver when the erroneous local settlement occurs, because it doesn't know yet that it is remotely settled (notification of which is still in flight or hasnt occurred at all). Similarly, I'd expect the local settlement to then mean the on_settled callback doesnt fire when the settled disposition arrives from the receiver. So those could just be two buggy runs where the behaviour differed because the frame timing did? {quote}I've checked and all the proton-c based bindings (actually python, C++, ruby, go) have exactly the same behaviour that the python binding does. So I'm not sure what "in other cases" means here? {quote} In particular I was thinking of a case outwith Qpid where I implemented auto-settle at Vert.x, ironically based on how I thought it was actually being done in the [other] Proton bindings, both at the time I did it and when writing that comment the other day. {quote}Another important thing we need to rectify is the documentation so that we explicitly call out what "automatic sender settlement" means. We should be explicit and say that the sender will settle automatically when it receives a settlement from the receiver with no intervention - Previously the conditions which provoked the automatic settlement were unspecified (but clearly important!). {quote} Agreed. The wording I used for a setter method for the above case was "Sets whether sent deliveries should be automatically locally-settled once they have become remotely-settled by the receiving peer." {quote}I will raise some extra JIRAs to cover the non python fixes and doc improvement. {quote} Great, thanks. Per above, it hadn't actually occurred to me that they all might be affected by the same issue! > [proton-python] on_settled callback not called when disposition arrives in 2 > frames > ------------------------------------------------------------------------------------ > > Key: PROTON-2056 > URL: https://issues.apache.org/jira/browse/PROTON-2056 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding > Affects Versions: proton-c-0.28.0 > Reporter: Ganesh Murthy > Priority: Major > Attachments: proton-2056.patch > > > When very large anonymous messages are sent to the router and these messages > have no receiver, they are immediately released. The router waits for the > entire large message to arrive in the router before settling it. Due to this, > in some cases, two disposition frames are sent for the same delivery, the > first has state=released and the second has settled=true as seen below > > {noformat} > 0x56330c891430]:0 <- @disposition(21) [role=true, first=315, > state=@released(38) []] > [0x56330c891430]:0 <- @disposition(21) [role=true, first=315, settled=true, > state=@released(38) []]{noformat} > > When this case happens, the on_settled is not called for the python binding. > The on_released is called. The on_settled must be called when a settlement > arrives for every delivery. I observed this behavior in a python system test > in Dispatch Router. The test called > test_51_anon_sender_mobile_address_large_msg_edge_to_edge_two_interior can be > found in tests/system_tests_edge_router.py > The test does not fail all the time but when it does it is due to the > on_settled not being called for deliveries that have this two part > disposition. > > I tried in vain to write a standalone python reproducer. I could not do it. > > To run the specific system test run the following from the > qpid-dispatch/build folder > > {noformat} > /usr/bin/python "/home/gmurthy/opensource/qpid-dispatch/build/tests/run.py" > "-m" "unittest" "-v" > "system_tests_edge_router.RouterTest.test_51_anon_sender_mobile_address_large_msg_edge_to_edge_two_interior"{noformat} > > The following is the test failure > {noformat} > test_51_anon_sender_mobile_address_large_msg_edge_to_edge_two_interior > (system_tests_edge_router.RouterTest) ... FAIL > ====================================================================== > FAIL: test_51_anon_sender_mobile_address_large_msg_edge_to_edge_two_interior > (system_tests_edge_router.RouterTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/gmurthy/opensource/qpid-dispatch/tests/system_tests_edge_router.py", > line 964, in > test_51_anon_sender_mobile_address_large_msg_edge_to_edge_two_interior > self.assertEqual(None, test.error) > AssertionError: None != u'Timeout Expired - n_sent=350 n_accepted=300 > n_modified=0 n_released=48' > ---------------------------------------------------------------------- > Ran 1 test in 17.661s > FAILED (failures=1) > {noformat} -- 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