Support specifying thread pool

[keirlawson]

Is your feature request related to a problem? Please describe.
I would love to see the SDK support passing in a thread pool upon client construction so that I can more precisely tune the number of threads my application uses to make best us of my available resources

Describe the solution you'd like
An additional construction option permitting a thread pool to be passed

Describe alternatives you've considered
None

Additional context
None

[eli-darkly]

I'm not sure this would be feasible. Here's a summary of how the SDK uses threads:

• Unless you're running offline or in polling mode, the SDK always has one long-running worker thread for managing the stream connection to LaunchDarkly.
• There is also one long-running worker thread that ingests analytics events from the LDClient.
• For delivering analytics events to LaunchDarkly, there is a fixed thread pool with a maximum size of 5. Normally only one of these is active at a time; it would only use additional threads from the pool if the LD events service was being very slow to respond.
• There is a single-threaded executor that handles all other background tasks. For instance, if you are using polling mode, the periodic polls are handled on this thread; if you're using a database integration and there is a database outage, it periodically polls the database status on this thread; and if you use notification features like FlagTracker.addStatusListener, listeners are called on this thread.

So, basically the only part of this where a variable-sized pool could make a difference is in the event delivery logic. The other threads are non-optional— if they were created from a pool that did not allow at least 4 concurrent threads, the SDK could not work. (We do allow configuration of the priority of worker threads— see LDConfig.Builder.threadPriority.)

We could certainly implement an option to customize the thread pool that's used for event delivery. However, it's possible that we might instead move to a different approach there, using java.nio asynchronous requests for the event data posts and putting a limit on the number of pending requests without actually making threads for them.

[eli-darkly]

I'm closing this issue for now, since there have been no replies and it's unclear to me whether the original description was meant to refer to something that wasn't addressed by my comment.