Default thread count for Async client

[pankajdighe]

This is regarding the following statement in document https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/asynchronous.html#advanced-operations

 By default, 50 Threads are generated for each asynchronous client.

I followed few discussions in previous issues and came across this line https://github.com/aws/aws-sdk-java-v2/blob/master/core/sdk-core/src/main/java/software/amazon/awssdk/core/client/builder/SdkDefaultClientBuilder.java#L301

could you please help me understand this configuration? Does this mean that default number of threads is not 50 and depends on number of processors?

could you please provide more context on following statement in same documentation?

This abstraction reduces the risk of an application breaking the async process if developers choose to stop or sleep threads

Also I would like to know if there is any documentation which describes the thread pool configuration while using AWS Async client?

Describe the issue

Links

[debora-ito]

Hi @pankajdighe thank you for reaching out.

The documentation is outdated, we don't use 50 threads by default anymore, you can see the discussion that led to the change in #1251. We'll work to update the docs.

You can still override the default configuration like is shown in the code examples in the Advanced Operations page.

Also I would like to know if there is any documentation which describes the thread pool configuration while using AWS Async client?

I don't think there is a documentation page besides the one you referenced. Are you looking for something specific?

[pankajdighe]

Hello @debora-ito thank you for sharing the updates. I have following questions specific to SDK async operations

1. Could you please provide more details on how SdkAdvancedAsyncClientOption.FUTURE_COMPLETION_EXECUTOR works in SDK? And how abstraction reduces the risk of an application breaking the async process if developers choose to stop or sleep threads?
2. How to optimize the thread pool configuration for SDK ? could you please share best practices around this? Which metrics we can monitor to optimize and scale our service?
3. Do you recommend to configure the netty client? If yes then how can we do this?
4. I would like to know if you can share the performance benchmark results?
5. What are different aspects we can consider to optimally use AWS SDK async client?

[bhoradc]

Hi @pankajdighe,

By default, 50 Threads are generated for each asynchronous client.

Sorry for the long delay in following up. The above documentation was corrected thanks to your report. Regarding your follow-up questions:

1. Could you please provide more details on how SdkAdvancedAsyncClientOption.FUTURE_COMPLETION_EXECUTOR works in SDK? And how abstraction reduces the risk of an application breaking the async process if developers choose to stop or sleep threads?
2. How to optimize the thread pool configuration for SDK ? could you please share best practices around this? Which metrics we can monitor to optimize and scale our service?

See the Javadoc for SdkAdvancedAsyncClientOption.FUTURE_COMPLETION_EXECUTOR. The default pool is separate from Netty's I/O threads, so blocking work in your callbacks affects only that pool.

3. Do you recommend to configure the netty client? If yes then how can we do this?

If you have a specific tuning need, the Netty configuration covers the knobs, and the HTTP client comparison covers the choice between async clients.

4. I would like to know if you can share the performance benchmark results?

If you have a specific performance concern you'd like us to look at, please share it.

5. What are different aspects we can consider to optimally use AWS SDK async client?

See the developer guide sections: Programming asynchronously , Best practices, Netty configuration

Closing this issue. If you still have specific concerns on any of these, please open a new issue with details. Thanks!

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.