[
https://issues.apache.org/jira/browse/PROTON-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853302#comment-16853302
]
Robbie Gemmell commented on PROTON-2056:
----------------------------------------
{quote}it is expected that the sender should respond to the release only
disposition with a settle
{quote}
I'm not sure it is expected. The example in the spec of this is for
exactly-once (though thats only noted later) which isnt being done here. I'm
not sure the spec specifically covers what happens in the unusual case of a
terminal outcome being sent as not settled by a peer that is meant to settle
first, but settling at the sender first regardless seems to go against the
general intent in my mind.
Another interesting thing would be transactional state (which can be updated
settled or not, and imposes behavioural differences) and how the delivery would
be impacted in the face of sender settling first.
I think the patch you proposed is the correct thing to do, its whats being done
in other cases.
The main thing here is perhaps just that Dispatch is actually being a bit odd
in not settling the message at the point of release, which I believe its only
doing at all due to PROTON-1914.
{quote}in the case where the sender settles a delivery that reported a terminal
state you should get an {{on_settled}} callback - this is because the delivery
has been settled at both receiver and sender.
{quote}
It hasn't necessarily been settled at the receiver, thats why we can get into
the situation.
It also seems that it would need to distinguish between an auto-settlement and
a regular-local-settlement, since it would seem a bit odd to me that you would
get a callback about a delivery settlement when you explicitly call settle,
which means you've forgot about it already and so couldnt action anything
provided by a callback.
Again I think the appropriate thing is to do what your patch does. You will get
an on_settled when they settle, if you have not already [explicitly] settled,
in which case you shouldnt get a callback (what do you do with a callback about
something you already indicated you have forgotten?).
> [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
