provide mechanism for supplying custom thread pool to AsyncMethodsClientImpl

[jahlbornG]

We have a custom ExecutorService implementation which includes additional logging context when executing a task. I would like to utilize this thread pool implementation with the slack AsyncMethodsClientImpl. currently, however, the thread pool implementations are provided via static calls to ExecutorServiceFactory. it would be ideal if, e.g., MethodsConfig provided an ExecutorService factory implementation which could be customized by the user of the sdk.

Category (place an x in each of the [ ])

• bolt (Bolt for Java)
• bolt-{sub modules} (Bolt for Java - optional modules)
• slack-api-client (Slack API Clients)
• slack-api-model (Slack API Data Models)
• slack-api-*-kotlin-extension (Kotlin Extensions for Slack API Clients)
• slack-app-backend (The primitive layer of Bolt for Java)

Requirements

Please make sure if this topic is specific to this SDK. For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. 🙇

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to the those rules.

[filmaj]

Hey @jahlbornG,

Thanks for writing in. This seems like a reasonable enhancement request to me. I am not an expert in this project but after taking a look at the code, it doesn't look like extending MethodsConfig with your suggestion would be too difficult. One thing to note is that if we decide to extend MethodsConfig in this way, we probably also want to do this for SCIMConfig and AuditConfig as well (all three Config interfaces follow a similar pattern).

There are other areas of the code that leverage the static method of creating ExecutorService instances from ExecutorServiceFactory, in particular: the socket mode implementation classes and the rate limiting metric data store classes. These areas seem more coupled together and on first glance I think it would be more difficult to expose to the user in some manner.

That all being said: I would love to hear from @seratch, this project's main steward, about his perception and opinion, as he likely knows the best path forward to tackle this!

[seratch]

@filmaj Thanks for providing the initial response!

@jahlbornG
We'll add a new interface to enable customizing the ExecutorService generation across the libraries in this SDK.

I'm thinking that we can go with:

• Add a new interface named ExecutorServiceProvider and enable users to implement it plus pass it to configs
• Replace ExecutorServiceFactory usage inside the SDK with customizable ExecutorServiceProvider objects
• Add custom ExecutorServiceProvider arguments in the config classes

diff --git a/slack-api-model/src/main/java/com/slack/api/util/thread/DefaultExecutorServiceProvider.java b/slack-api-model/src/main/java/com/slack/api/util/thread/DefaultExecutorServiceProvider.java
new file mode 100644
index 00000000..a4e54368
--- /dev/null
+++ b/slack-api-model/src/main/java/com/slack/api/util/thread/DefaultExecutorServiceProvider.java
@@ -0,0 +1,4 @@
+package com.slack.api.util.thread;
+
+public class DefaultExecutorServiceProvider implements ExecutorServiceProvider {
+}
diff --git a/slack-api-model/src/main/java/com/slack/api/util/thread/ExecutorServiceProvider.java b/slack-api-model/src/main/java/com/slack/api/util/thread/ExecutorServiceProvider.java
new file mode 100644
index 00000000..e849bb85
--- /dev/null
+++ b/slack-api-model/src/main/java/com/slack/api/util/thread/ExecutorServiceProvider.java
@@ -0,0 +1,15 @@
+package com.slack.api.util.thread;
+
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.ScheduledExecutorService;
+
+public interface ExecutorServiceProvider {
+
+    default ExecutorService createThreadPoolExecutor(String threadGroupName, int poolSize) {
+        return ExecutorServiceFactory.createDaemonThreadPoolExecutor(threadGroupName, poolSize);
+    }
+
+    default ScheduledExecutorService createThreadScheduledExecutor(String threadGroupName) {
+        return ExecutorServiceFactory.createDaemonThreadScheduledExecutor(threadGroupName);
+    }
+}

Please feel free to write in if you have different views or alternative ways!