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 <josiahn...@gmail.com> 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 > <https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java#L200-L204> > . > > For backward compatibility I don't think we will ever >> change that default behaviour. > > > Can you expand on this a little more? Is the backwards incompatibility > that it would be able to serve more than a single request at the same time? > > An executor can however be supplied to the HttpServer >> using `HttpServer.setExecutor` [1] > > > After using this method for so long, I'm wondering if there is any reason > that we have to go through this ceremony to serve more than one request at > the same time. (Every time I've used it) > > Their might still be some side effect with using >> virtual thread however, especially if invoking code >> calling a native method that blocks, or loading a class >> that blocks in its static initializers. > > > As you say, the default dispatcher currently runs serially, so if one does > any sort of blocking operation, the dispatcher thread is pinned and cannot > serve any more requests. If one were to switch to a virtual thread executor > and call native blocking methods, is there a difference in this scenario? > Either way, the server would be unable to serve requests while the thread > is pinned by the blocking operation. > > On Tue, May 13, 2025 at 2:28 PM Daniel Fuchs <daniel.fu...@oracle.com> > wrote: > >> 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 >> using `HttpServer.setExecutor` [1] >> >> The HttpServer mostly uses monitors for synchronization. >> With JEP 491 delivered [2], using Virtual Threads with >> the HttpServer has become more friendly, and anyone wishing >> to use VirtualThread with their HttpServer instance >> can therefore pass a VirtualThreadPerTaskExecutor to >> their instance. >> >> Their might still be some side effect with using >> virtual thread however, especially if invoking code >> calling a native method that blocks, or loading a class >> that blocks in its static initializers. >> >> So using VirtualThread should be a conscious choice >> from the application designers. >> >> If you are speaking of `jwebserver` - then we deliberately >> choose to not use any executor there, and I don't think we >> would change that. >> >> best regards, >> >> -- daniel >> >> [1] >> >> https://docs.oracle.com/en/java/javase/24/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpServer.html#setExecutor(java.util.concurrent.Executor) >> [1] https://openjdk.org/jeps/491 >> >> On 13/05/2025 18:17, Josiah Noel wrote: >> > Hey Team, >> > >> > Has there been any discussion about changing the default executor of >> the >> > JDK HTTP server implementation to use virtual threads? >> > >> >>
