[jira] [Commented] (PROTON-2056) [proton-python] on_settled callback not called when disposition arrives in 2 frames

["Robbie Gemmell (JIRA)" <ji...@apache.org>]

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

Robbie Gemmell commented on PROTON-2056:
----------------------------------------

{quote}I think you are confusing sender and receiver semantics.
{quote}
I'm not.
{quote}For a sender receiving a terminal state disposition is notification that it can forget all about the delivery (in other words settle). There is nothing further it can do irrespective of the delivery mode. So even though this case is presumable at-least-once the very fact that we've received a terminal state update means we can forget the delivery even though the receiver has not actually told us it has settled yet.
{quote}
For non-transacted at-least-once cases I can agree that in practical terms thats likely effectively true. However its still going against what the protocol describes (settlement is a separate thing) plus what the link has been negotiated as doing (receiver settles first), and with no real benefit that I can see, just adding requirement for a more complicated local implementation without real need that might have side effects.
{quote}So presuming that the purpose of the on_settled callback is for application delivery state management, the bug here is that the on_settled callback isn't happening when the sender receives the terminal state update.
{quote}
I presume the on_settled callback is for notification of the delivery being settled by the receiver, which if it hasnt yet been, means it shouldnt be called. If the app explicitly settles it locally then it also shouldnt be called (since we just said we already forgot about it so what good what that be?).

If we start 'making up' local settlements upon receiving unsettled terminal states we would then have to distinguish these implicit ones and explicit local settlements which seems like unnecessary complication.
{quote}As for transaction state updates - they aren't terminal state updates in general (unless I misunderstand them) and so receiving an update for transaction state shouldn't have any implication for settlement.
{quote}
Transacted deliverys tend never to have a terminal state directly applied, since the to-be-effective outcome is conveyed inside a non-terminal transactional state so that the transaction it relates to can be identified. The delivery's settlement plays into the effective behaviour of the state application in relation to discharge of the transaction and can significantly change the behaviour.

 

I continue to see no reason for adding such complication versus making the simple 'add indent' change, which apparently fixes the issue without having the sender effectively violate the protocol in the rare cases Dispatch should do the multiple-disposition (which could be avoided by fixing the other actual bug), and without needing to make distinctions between terminal and non terminal outcomes, or explicit and implicit local settlements, or considering any unintended impact on other areas such as transactions.

> [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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org