[
https://issues.apache.org/jira/browse/DISPATCH-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219561#comment-17219561
]
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_r510745814
##########
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.
>
No, it isnt a great hardship, I just wondered why this version went back to
doing it, when the previous version expressly went the opposite way, is all.
Though note the value doesnt really demonstrate how many transfer frames are
in flight at all in Protons case. It allows seeing how many max-size frames it
would take to cover all the data recieved but not yet read out of all the
receivers on the session combined at that point. The number of frames
receieved and their effect on the window size become largely decoupled from
that (unlesss essentially all arriving frames are max-size too). You can reason
about the size of combined data yet to be read, though without indication where
it is to be read from / what frames its for (except the single receiver case to
an extent).
> > 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.
>
Its provoking the same [initial] window as it would get from proton if
nothing were set, so its not really proving that.
> > 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 understand all that already, especially given I largely explained the
original issue, it doesnt really relate to what I was aiming at with my
comment, however at this point...
> I propose that we commit this patch and move on.
I can tell you are fed up with the matter, and I'm likely more fed up
discussing it, so by all means.
----------------------------------------------------------------
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
