[
https://issues.apache.org/jira/browse/PROTON-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173985#comment-17173985
]
Robbie Gemmell edited comment on PROTON-2255 at 8/9/20, 10:36 PM:
------------------------------------------------------------------
{quote}If maxSessionFrames is not set in the router config, it defaults to zero
which means unlimited window in which case why not allow proton to set the
default incoming window (#define AMQP_MAX_WINDOW_SIZE (2147483647)) using
pni_session_incoming_window ? {quote}
Thats my point, I dont see why Dispatch wouldnt simply omit setting a session
capacity when maxSessionFrames isnt set, thus giving Protons default of using
the fixed AMQP_MAX_WINDOW_SIZE (2147483647) frames value for the incoming
window on each flow. By doing what it does instead, which doesnt seem to
entirely match what the above description says, then on 64bit systems it
explicitly sets a gigantic session capacity of 35184372072448 (32 TB!)
resulting in proton using the 16384 frame size and calculating the same
2147483647 value for the amount of frames for the incoming window. Except this
time the window will need to be re-calculated precisely for each flow sent as a
result of a session capacity and max frame size both being set, so it may vary
if there are unread delivery bytes outstanding. In the 32bit case, it seemingly
sets the session capacity to merely 2147483647 instead, resulting in the window
instead being calculated as the lower 131071 initially.
{quote}
It seems to me that the goal of Dispatch is to allow for an incoming window
that is larger than the proton default.
{quote}
I dont think that is the case. The router can govern the incoming window being
put in place with the settings that are available (though I very doubt more
than 2 billion frames in the window would be usefully different very often).
The issue here is around its default behaviour when those controls are not set
though. The idea there is to effectively not have a window (instead rather,
just always set that really large window value), but the router then goes to
the effort of specifically setting one up, but configures for a much smaller
one in the 32bit case.
EDIT: though maybe I misunderstand and you are saying the goal is not to rely
on protons default behaviour, should it somehow become lower than what Dispatch
wants. I dont see that happening, though the router could tell if it did and
just set the values up to its liking instead.
was (Author: gemmellr):
{quote}If maxSessionFrames is not set in the router config, it defaults to zero
which means unlimited window in which case why not allow proton to set the
default incoming window (#define AMQP_MAX_WINDOW_SIZE (2147483647)) using
pni_session_incoming_window ? {quote}
Thats my point, I dont see why Dispatch wouldnt simply omit setting a session
capacity when maxSessionFrames isnt set, thus giving Protons default of using
the fixed AMQP_MAX_WINDOW_SIZE (2147483647) frames value for the incoming
window on each flow. By doing what it does instead, which doesnt seem to
entirely match what the above description says, then on 64bit systems it
explicitly sets a gigantic session capacity of 35184372072448 (32 TB!)
resulting in proton using the 16384 frame size and calculating the same
2147483647 value for the amount of frames for the incoming window. Except this
time the window will need to be re-calculated precisely for each flow sent as a
result of a session capacity and max frame size both being set, so it may vary
if there are unread delivery bytes outstanding. In the 32bit case, it seemingly
sets the session capacity to merely 2147483647 instead, resulting in the window
instead being calculated as the lower 131071 initially.
{quote}
It seems to me that the goal of Dispatch is to allow for an incoming window
that is larger than the proton default.
{quote}
I dont think that is the case. The router can govern the incoming window being
put in place with the settings that are available (though I very doubt more
than 2 billion frames in the window would be usefully different very often).
The issue here is around its default behaviour when those controls are not set
though. The idea there is to effectively not have a window (instead rather,
just always set that really large window value), but the router then goes to
the effort of specifically setting one up, but configures for a much smaller
one in the 32bit case.
> [proton-c] unexpected incoming-window in begin frame when running Dispatch
> test in 32 bit system
> ------------------------------------------------------------------------------------------------
>
> Key: PROTON-2255
> URL: https://issues.apache.org/jira/browse/PROTON-2255
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: proton-c-0.31.0
> Reporter: Ganesh Murthy
> Priority: Major
>
> system_tests_protocol_settings fails in Dispatch with the following error
>
> {noformat}
> ======================================================================
> FAIL: test_connector_default
> (system_tests_protocol_settings.ConnectorSettingsDefaultTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/home/jenkins/workspace/rh-qpid-dispatch-dist-el6-32-master/build/BUILD/qpid-dispatch-1.13.0/tests/system_tests_protocol_settings.py",
> line 343, in test_connector_default
> self.assertTrue(" incoming-window=2147483647," in begin_lines[0])
> AssertionError: False is not True
> ======================================================================
> FAIL: test_max_frame_max_session_zero
> (system_tests_protocol_settings.MaxFrameMaxSessionFramesZeroTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/home/jenkins/workspace/rh-qpid-dispatch-dist-el6-32-master/build/BUILD/qpid-dispatch-1.13.0/tests/system_tests_protocol_settings.py",
> line 287, in test_max_frame_max_session_zero
> self.assertTrue(" incoming-window=2147483647," in begin_lines[0])
> AssertionError: False is not True
> ======================================================================
> FAIL: test_max_session_frames_default
> (system_tests_protocol_settings.MaxSessionFramesDefaultTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/home/jenkins/workspace/rh-qpid-dispatch-dist-el6-32-master/build/BUILD/qpid-dispatch-1.13.0/tests/system_tests_protocol_settings.py",
> line 249, in test_max_session_frames_default
> self.assertTrue(" incoming-window=2147483647," in begin_lines[0])
> AssertionError: False is not True {noformat}
>
> The actual line in the log is
> {noformat}
> 2020-07-30 12:47:53.727396 -0400 PROTOCOL (trace) [3]:FRAME: 0 <-
> @begin(17) [next-outgoing-id=0, incoming-window=131071,
> outgoing-window=2147483647]
> (/root/project/build/BUILD/qpid-dispatch-1.13.0/src/server.c:112) {noformat}
>
> The test is expecting to see the incoming-window to be 2147483647 but instead
> gets 131071.
> This could be a possible issue with the way the incoming-window is logged but
> really not sure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
