Re: [jetty-users] Client threads - can they be daemon threads?

[Simone Bordet <sbordet@xxxxxxxxxxx>]

Hi,

On Wed, Jun 14, 2023 at 7:50 PM Shawn Heisey <eclipse@xxxxxxxxxxxx> wrote:
>
> 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?

Yes.

> 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.

That seems to be the case.

>  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.
> -

You typically want to configure the thread pool, then configure the
HttpClient and then start it and never change the daemon-ness of
threads after you started HttpClient, so thread safety is not a
problem.

> 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.

Then it's a question for SolrJ.
I do not know their APIs, but they should expose the configuration to
make threads deamon.

Having said that, I still think it would be much better to link
HttpClient to some application lifecycle and stop it when the
application stops, so that it is stopped cleanly without making
threads daemon.

Your point about uncaught exception handlers seems very weak to me, as
you may as well say that if an exception is uncaught then you just
call System.exit(1), and you don't worry about daemon threads.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.