Proposal: Managing the Lifecycle of THREAD_POOL in Azure Table Storage Java SDK

[luxianlong]

Hello Azure SDK Community,

I've been working with the Azure Table Storage Java SDK and encountered a scenario that I believe could benefit from a discussion and potential enhancement. Specifically, I'm referring to the management of the THREAD_POOL used in the TableClient and TableAsyncClient classes for handling asynchronous operations.

As it stands, the SDK initializes a static THREAD_POOL using Executors.newCachedThreadPool() and registers a JVM shutdown hook to clean up the thread pool. This approach generally works well for straightforward applications. However, it poses challenges in scenarios where the application has specific requirements for shutdown behavior or needs to manage the thread pool lifecycle more granitely.

For example, in my case, I need to perform certain operations against Azure Table Storage within my application's shutdown hook. The current implementation of the SDK's thread pool management doesn't easily allow for this, as the thread pool may be shut down before my shutdown logic executes.

I propose we discuss potential enhancements to the SDK that would give developers more control over the thread pool's lifecycle. Some ideas could include:

• Providing a way to customize the ExecutorService: Allowing users to supply their own ExecutorService implementation could enable more sophisticated thread management strategies and integration with application-specific lifecycle management.
• Exposing thread pool management operations: Adding methods to start, stop, or restart the thread pool could offer the necessary hooks for applications to manage the thread pool according to their lifecycle events.
• Support for graceful shutdown: Enhancing the SDK to support graceful shutdown of the thread pool, with the ability to wait for active tasks to complete before shutting down, could be beneficial for ensuring data integrity and completeness of operations.

I'm interested in hearing the community's thoughts on this matter.

Thank you.

[alzimmermsft]

Thanks for starting this discussion @luxianlong, this is something that we're looking at right now. We recently added a centralized ExecutorService into our azure-core library so that downstream SDKs don't need to manage their own thread pools:

#38860

And at one part during the implementation, I did have a way to set an external ExecutorService that would be used instead of one managed by the Azure SDK itself.

Would you mind opening this up as an issue?

[luxianlong]

Hi, @alzimmermsft , thanks for your answer. I've opened this as an issue: #40250