[zoewangg]

Not ready to merge. On HTTP/2, this change depends on an upcoming aws-crt-java release in which the HTTP/2 stream manager honors the pending-acquisition limit. This PR stays on the current awscrt.version (0.50.0) for now. It can merge only after that release exists and this PR bumps awscrt.version to it. Until then, AwsCrtMaxPendingConnectionAcquiresTest.asyncExecuteH2_overLimit_failsFutureWithNonRetryableHttpException fails, by design.

Motivation and Context

NettyNioAsyncHttpClient.Builder has maxPendingConnectionAcquires, which limits how many requests to one endpoint can wait once all connections (HTTP/1.1) or streams (HTTP/2) are in use. The AWS CRT HTTP clients have no equivalent: waiting requests are unbounded. Workloads that rely on this option to shed load cannot move from Netty to the CRT client with the same behavior.

Modifications

• Add maxPendingConnectionAcquires(Integer) to AwsCrtAsyncHttpClient.Builder and AwsCrtHttpClient.Builder, with the same name, type and meaning as the Netty option. It is implemented once in the shared builder base.
  • Unset or null means unbounded, which is the current CRT behavior. Netty's default is 10,000; the Javadoc says to set it explicitly to keep the Netty behavior when migrating.
  • Zero or negative values throw IllegalArgumentException at the builder call.
  • The value is kept on the builder rather than in the AttributeMap, so SdkHttpConfigurationOption.MAX_PENDING_CONNECTION_ACQUIRES from the global or service defaults does not apply to the CRT clients.
• The value is passed to HttpClientConnectionManagerOptions.withMaxPendingConnectionAcquisitions only when set. These are the connection-manager options the client already hands to the HTTP/2 stream manager.
• A request over the limit fails immediately with the CRT HttpException (error code 2094) and is not sent. 2094 is removed from the CRT client's additionally-retryable error codes, so the rejection is not retried, matching Netty. Before this change, the SDK never set the limit, so 2094 could not occur.
• Javadoc for connectionAcquisitionTimeout and connectionMaxIdleTime on AwsCrtAsyncHttpClient.Builder now describes their HTTP/2 behavior with the upcoming CRT release:
  • On HTTP/2, the acquisition timeout bounds only the wait for a new connection, not the wait for a stream.
  • The max idle time applies to both protocols.

Testing

• New AwsCrtMaxPendingConnectionAcquiresTest, using WireMock for HTTP/1.1 and an in-test HTTP/2 server:
  • builder validation;
  • async and sync rejection over the limit, which is not an IOException and has error code 2094;
  • the rejected request is never sent;
  • unbounded when unset;
  • the service-default value is ignored;
  • HTTP/2 rejection.
• CrtUtilsTest: 2094 is returned unchanged, not wrapped as a retryable IOException.
• aws-crt-client module build, on macOS with the default TLS stack and with s2n (AWS_CRT_USE_NON_FIPS_TLS_13=1): 396 tests run. The only failure is the HTTP/2 rejection test, which needs the upcoming aws-crt-java release; on 0.50.0 the third request waits instead of being rejected. Checkstyle, SpotBugs and the other static checks pass.
• I built only the affected module, not a full mvn install.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license

[zoewangg]

Removing 2094 from the retryable codes doesn't change behavior for existing users because it was basically unreachable until now. aws-c-http only raises 2094 when max_pending_connection_acquisitions is set, and the SDK never set it (HttpClientConnectionManagerOptions.withMaxPendingConnectionAcquisitions was never called).

The reason we removed it here is to match netty behavior; we don't retry max pending acquisitions error for netty