[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jetty-users] Client threads - can they be daemon threads?
|
On 6/14/23 11:05, Simone Bordet wrote:
It is already available:
QueuedThreadPool threadPool = new QueuedThreadPool(...);
threadPool.setDaemon(true);
HttpClient httpClient = new HttpClient();
httpClient.setExecutor(threadPool);
httpClient.start();
Is that Jetty code?
This is the code in SolrJ's "Http2SolrClient" that creates the jetty client:
https://paste.elyograg.org/view/e4c9ede9
I suspect that the code path quoted above is not being used by SolrJ,
that SolrJ is managing the thread pool and is not creating threads with
the daemon flag. If I am wrong, then this info/query will be valid:
-
I was able to access source for QueuedThreadPool in my IDE for my
project using SolrJ. I see that the boolean flag (_daemon) changed by
the setDaemon call is being used when a new thread is created. Is there
any chance that the _daemon field in QueuedThreadPool is having thread
safety problems? If it were me doing this, I would use AtomicBoolean
rather than boolean for that, even if I thought there couldn't possibly
be thread safety issues.
-
Should SolrJ just let Jetty handle its own thread pool? Is that pool
object MDC aware? MDC awareness is the only reason I can imagine that
somebody thought it was a good idea for SolrJ to handle Jetty threads
itself. I do not see anything in the executor objects used by SolrJ
that would cause it to create daemon threads.
Thanks,
Shawn