[
https://issues.apache.org/jira/browse/DISPATCH-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219391#comment-17219391
]
ASF GitHub Bot commented on DISPATCH-1751:
------------------------------------------
ChugR commented on a change in pull request #890:
URL: https://github.com/apache/qpid-dispatch/pull/890#discussion_r510531874
##########
File path: src/connection_manager.c
##########
@@ -438,25 +438,35 @@ static qd_error_t load_server_config(qd_dispatch_t *qd,
qd_server_config_t *conf
config->max_frame_size = QD_AMQP_MIN_MAX_FRAME_SIZE;
//
- // Given session frame count and max frame size compute session
incoming_capacity
+ // Given session frame count and max frame size, compute session
incoming_capacity
+ // On 64-bit systems the capacity has no practial limit.
+ // On 32-bit systems the largest default capacity is half the process
address space.
//
- if (ssn_frames == 0)
- config->incoming_capacity = (sizeof(size_t) < 8) ? 0x7FFFFFFFLL :
0x7FFFFFFFLL * config->max_frame_size;
- else {
- uint64_t mfs = (uint64_t) config->max_frame_size;
- uint64_t trial_ic = ssn_frames * mfs;
- uint64_t limit = (sizeof(size_t) < 8) ? (1ll << 31) - 1 : 0;
- if (limit == 0 || trial_ic < limit) {
- // Silently promote incoming capacity of zero to one
- config->incoming_capacity =
- (trial_ic < QD_AMQP_MIN_MAX_FRAME_SIZE ?
QD_AMQP_MIN_MAX_FRAME_SIZE : trial_ic);
+ bool is_64bit = sizeof(size_t) == 8;
+#define MAX_32BIT_CAPACITY ((size_t)(2147483647))
+ if (ssn_frames == 0) {
+ config->incoming_capacity = is_64bit ? MAX_32BIT_CAPACITY *
(size_t)config->max_frame_size : MAX_32BIT_CAPACITY;
Review comment:
> I dont really understand why this version goes back to always setting
a capacity for the 64bit system, even in the default 'not really doing flow
control' situation? Doing so causes the window to be precisely recomputed with
every flow frame sent again, as it was to begin with. Wasnt that one of the
things we wanted to stop with these changes?
>
But the window is computed to precisely *different* values as the window is
slowly consumed. Showing precisely the same value gives no indication of how
many transfers are in flight. Having proton show the precise, *correct* value
is not a big hardship: a subtraction and division per window calculation.
> Specifically calculating a ~32TB default capacity (when considering the
default 16KB frames size) as this does for the 64bit system, just to have
setting this session capacity value then cause proton to [repeatedly] calculate
the the same peak value for the window as it it would simply used were nothing
set, seems as odd now as it did to start with.
>
Forcing Proton to use the values we expect it to use allows test code to
prove that those values are actually being used.
> Capping the 32bit system at half its address space by default can
certainly be argued given its the same limit applied by Dispatch in the
calculations based on user-configuration. Plus its more likely to occur being
that it is only 2GB. Though practicaly im not sure leaving it uncapped by
default would be that relatively different from the 64bit case being given
32TB, neither is that likely to cope with such a window being filled (or there
being other sessions each with their own limit..).
>
AMQP protocol allows a max-frame-size in bytes and an incoming-window in
frames. Proton allows a max-frame-size in bytes and a capacity in bytes.
Furthermore, the Proton capacity is a size_t type which varies in its maximum
values between 32-bit and 64-bit systems.
DIspatch listeners and connectors allowed maxFrameSize and maxSessionFrames
(incoming-window) settings to directly match the AMQP protocol. If Proton
offered those same two settings then this issue between 32-bit and 64-bit
systems would never have happened.
I propose that we commit this patch and move on.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> unexpected incoming-window in begin frame when running Dispatch on 32 bit
> system
> --------------------------------------------------------------------------------
>
> Key: DISPATCH-1751
> URL: https://issues.apache.org/jira/browse/DISPATCH-1751
> Project: Qpid Dispatch
> Issue Type: Bug
> Affects Versions: 1.13.0
> Reporter: Ganesh Murthy
> Priority: Major
> Fix For: 1.15.0
>
>
> On 32bit systems, an unexpected incoming-window value is set. This for
> example causes system_tests_protocol_settings failures on 32bit systems, with
> test expecting to see the incoming-window be 2147483647 but instead finding
> it much less, e.g 131071.
> This is due to the way the session capacity is configured, particularly on
> 32bit systems. See more details (output, code, etc) from prior discussions on
> PROTON-2255 (raised when this was incorrectly thought to be a proton issue).
--
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
