As a user of AWS Lambda, I would like to be able to configure TCP client keep-alive for sdk clients via ClientOverrideConfiguration.
The 1.11.x sdk supported this configuration like so:
new ClientConfiguration().withTcpKeepAlive(true);
Based on how the new ClientOverrideConfiguration.Builder works, I'd like to see something like this make the same kind of configuration:
ClientOverrideConfiguration.builder().tcpKeepAlive(true).build();
According to the 1.11 to 2.0 changelog this feature is currently unsupported.
Setting TCP keep-alive in client configuration for various 1.11 AWS clients (AmazonSNS, AmazonDynamoDB, AmazonSNS, etc.) that are reused between AWS Lambda invocations significantly reduces the running time (and thus cost) of our serverless architecture.
Supporting this override directly in the SDK will help keep our code clean and ensure that we can keep leveraging the benefits of static utility reuse between Lambda invocations.
+1. The feature will have to be done at the HTTP client level, but this makes sense to include, and should be relatively easy.
If this is urgent, pull requests get through more quickly than features we add ourselves. We can't give any timeline for when we can build the feature ourselves.
Shouldn't this have the 1.11.x parity label?
I am probably missing the point, but I have configured netty like this:
DynamoDbAsyncClient.builder
.httpClientBuilder(
NettyNioAsyncHttpClient
.builder()
.putChannelOption(ChannelOption.SO_KEEPALIVE, true)
)
Is it enough to enable keep-alive on the client-side?
Since 2.16.38, it's also possible to do this with the Apache HTTP client.
LambdaClient.builder().httpClient(
ApacheHttpClient.builder()
.tcpKeepAlive(true)
.build()
);
Most helpful comment
+1. The feature will have to be done at the HTTP client level, but this makes sense to include, and should be relatively easy.
If this is urgent, pull requests get through more quickly than features we add ourselves. We can't give any timeline for when we can build the feature ourselves.