[ https://issues.apache.org/jira/browse/PROTON-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173985#comment-17173985 ]
Robbie Gemmell commented on PROTON-2255: ---------------------------------------- {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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org