[ https://issues.apache.org/jira/browse/PROTON-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852266#comment-16852266 ]
Andrew Stitcher commented on PROTON-2056: ----------------------------------------- I'm assuming this is a trace of the new behaviour. In that case I don't understand it at all. In fact I don't understand the trace when the test succeeds - Where are the dispositions from sender->receiver for delivery settlement? It makes no sense for this change to add a disposition frame for settlement when it specifically means that dlv.settle() isn't called at the point where that extra frame is being transmitted. [~gemmellr] Do you have any thoughts. What am I missing? Is it correct that the sender isn't sending settlement dispositions to the receiver? > [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