Evaluate and trim down the thread pools of a TransportClient

[bleskes]

At the moment, for simplicity, the ThreadPool used by the TransportClient is the same as a full blown node. I.e., we have pools for things like BULK , SEARCH which are not relevant. Since we create threads lazily it's typically not a big deal as we will not spawn too many threads. However, it is error prone and conveys the wrong message to people extending functionality around the client like a BulkProcessor. IMO we should have a trimmed down set.

[s1monw]

+1 - we might go even further and move all the threadpool stuff into a module and allow only this module to spawn threads etc? I know this is not what this issue is for but I wanted to get the idea out as @rmuir mentioned it to me a couple of times and I think it makes sense

[bleskes]

Sounds good to me

On 16 dec. 2015 10:12 AM +0100, Simon [email protected], wrote:

+1 - we might go even further and move all the threadpool stuff into a module and allow only this module to spawn threads etc? I know this is not what this issue is for but I wanted to get the idea out as@rmuir(https://github.com/rmuir)mentioned it to me a couple of times and I think it makes sense

—
Reply to this email directly orview it on GitHub(#15472 (comment)).

[javanna]

Given that the high-level REST client will replace the transport client, I think that #26727 relates to this proposal, and may actually end up closing it.

[javanna]

Quick update: the Java high-level REST client no longer requires a ThreadPool but rather a lighter weight Scheduler which wraps a ScheduledThreadPoolExecutor. Given that we don't intend to spend time on fixing this in the transport client, and the current solution for the REST client is good, I am closing this issue.