The default HttpServer Executor

[Ethan McCue]

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 <josiahnoel at 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.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/ce286f68/attachment-0001.htm>