[
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: [email protected]
For additional commands, e-mail: [email protected]
