User can't manage the lifecycle of THREAD_POOL in Azure Table Storage Java SDK

[luxianlong]

Discussed in #40107

^{Originally posted by luxianlong May 10, 2024}
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 posting this @luxianlong, I personally would prefer a case where the ExecutorService can be set externally as this is the most powerful mechanism and could integrate with existing threading logic used within an application. Since you posted this, would your expectation be that this ExecutorService would need to be set before running any SDK operations or could be set at any point during the lifetime of the application?

[luxianlong]

Hi, @alzimmermsft , from my personal perspective, I think the ExecutorService could be set at any point during the lifetime of the application. If you didn't set the ExecutorService, then the application will use the default one.

[alzimmermsft]

@luxianlong, with #41885 this should be doable now (as long as the downstream service SDK consumes SharedExecutorService rather than creating its own). There will be further work in this area in the future to push a provided ExecutorService rather than relying on ones we create.

[github-actions]

Hi @luxianlong. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.