[
https://issues.apache.org/jira/browse/DISPATCH-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219208#comment-17219208
]
ASF GitHub Bot commented on DISPATCH-1751:
------------------------------------------
gemmellr commented on a change in pull request #890:
URL: https://github.com/apache/qpid-dispatch/pull/890#discussion_r510335257
##########
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?
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.
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..).
----------------------------------------------------------------
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:
[email protected]
> 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: [email protected]
For additional commands, e-mail: [email protected]
