tree 491dd5cfd9c24abc4f28b7595871d2cdefb7a65e
parent c1a7f59baaf0ba5944074b3c9544732538b2e310
author Chuck Rolke <chug@apache.org> 1603461143 -0400
committer Chuck Rolke <chug@apache.org> 1603461143 -0400

DISPATCH-1751: Fix 32-bit self test receiving unexpected incoming-capacity

Dispatch listener config defines a 'maxFrameSize' and a 'maxSessionFrames'.
The idea is to have the 'maxFrameSize' go out in AMQP Open frames as
'max-frame-size' and the 'maxSessionFrames' go out in AMQP Begin frames
as 'incoming-capacity'.

To accomplish this Proton accepts a maxFrameSize and a capacity.
For Dispatch to get Proton to emit the 'incoming-capacity' then Dispatch
must specify 'capacity' as the product of 'maxFrameSize' and
'maxSessionFrames'. Furthermore, Proton specifies the capacity value
as a system-dependent 'size_t' value type.

For 64-bit systems the chosen defaults work just fine although the
capacity is a huge 30+ Terabytes. For 32-bit systems the 30+ Tb number
does not work since that does not fit into a 32-bit size_t. Dispatch
uses a smaller fallback maximum for 32-bit systems.

The self test was failing on 32-bit systems because the self test did not
account for the 32-bit smaller fallback maximum.

This patch fixes the self test to account for the fallback maximum on
32-bit systems.

This patch also rewrites for readability the 32-bit/64-bit capacity
calculations in the mission C code. It also computes capacity values
using 64-bit numbers even on 32-bit systems to avoid size_t overflow
truncation errors.

This patch does *not* use a different strategy for driving Proton to
use simpler calculation methods when essentially unlimited capacity
values are in effect.

Future work in this area might address some of the issues brought up
during Pull Request reviews. Thank you to the reviewers!

* Modify Proton to accept an 'incoming-capacity' value instead of or
in addition to 'capacity'.

* Modify Dispatch not to set a capacity at all in Proton when no flow
control in effect.

This closes #890