Re: [External] : Re: The default HttpServer Executor

> > Yes. An application (handler's implementations) may depend on that. Aside from that filter bug Ethan mentioned, have you seen such cases? I usually see people take it as a given that the default impl can serve multiple requests and have to tell them to use an executor. If we decide against c

Re: [External] : Re: The default HttpServer Executor

Hi Josiah, On 13/05/2025 20:24, Josiah Noel wrote: The HttpServer doesn't use any default executor I know what you mean by this, but I have to point out that the class used is quite literally called DefaultExecutor

Re: The default HttpServer Executor

I don't have any opinion besides best do nothing, but I will note that any multi threaded executor will make apparent the existing bug/spec issue in Filter that we talked about before. On Tue, May 13, 2025, 9:27 PM Josiah Noel wrote: > The HttpServer doesn't use any default >> executor > > > I k

Re: The default HttpServer Executor

> > The HttpServer doesn't use any default > executor I know what you mean by this, but I have to point out that the class used is quite literally called DefaultExecutor

Re: The default HttpServer Executor

Hi Josiah, The HttpServer doesn't use any default executor - it has one dispatcher thread and by default serves requests serially from the dispatcher thread. For backward compatibility I don't think we will ever change that default behaviour. An executor can however be supplied to the HttpServer

The default HttpServer Executor

Hey Team, Has there been any discussion about changing the default executor of the JDK HTTP server implementation to use virtual threads? -- Cheers, Josiah.