The default HttpServer Executor

[Josiah Noel]

>
> 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.fuchs at 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?
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250513/85c3c918/attachment.htm>