Determine whether to store threadPool in BaseExtension/SDK or initialize it in the extension itself.

[ryanbogan]

Currently, threadPool is an instance variable in BaseExtension and is initialized within the SDK. This issue will determine whether to continue with the current practice or initialize it in the actual extension.

[dbwiddis]

The ExtensionRunner / BaseExtension / Extension are all the same JVM and same threadpool.

If we already have it, it should be available for anyone to use.

[dbwiddis]

I've been thinking about this in the context of the various places we will run Extensions. It makes sense to just have a thread pool object on the ExtensionsRunner which will be accessible from extensions (via base extension setter as of #244).

• If run on a separate server by themselves, the Extensions need their own thread pool (or can run single-threaded)
• If run on a separate server along with other extensions, they may want to share a thread pool with other extensions
  • A single java instance could use its main method to launch multiple extensions via ExtensionsRunner.run(new ExtensionOne()); ExtensionsRunner.run(ExtensionTwo()); and so on.
  • In this case the ExtensionsRunner could have a thread pool object that the extensions can (optionally) set or get such as runner1 = ExtensionsRunner.run(new ExtensionOne()); runner2 = ExtensionsRunner.run(new ExtensionTwo()); runner2.setThreadPool(runner1.getThreadPool());
• If run "in proc" in the same JVM as OpenSearch, we probably want to share the same thread pool via setter as above.
• If run on the same server but different JVM as OpenSearch, we want to use the same thread pool (since its size is based on processing capability)...
  • But they are different JVMs so we can't share the same object.
  • We probably want some sort of transport mechanism to communicate thread needs and dynamically change thread pool size
  • This is a hard problem