spring-projects / spring-boot

Spring Boot helps you to create Spring-powered, production-grade applications and services with absolute minimum fuss.
https://spring.io/projects/spring-boot
Apache License 2.0
75.18k stars 40.68k forks source link

Jetty support doesn't set virtual thread name #40152

Closed holgerstolzenberg closed 7 months ago

holgerstolzenberg commented 7 months ago

I am using Spring Boot 3.2.4 with Jetty (spring boot supplied version) in a 'standard' web mvc project.

When activating the virtual threads feature through configuration within application.yml the logging of the thread names disappears. I am using the default log pattern supplied by spring boot.

I suspect it is related to JettyVirtualThreadsWebServerFactoryCustomizer only using threadPool.setVirtualThreadsExecutor(VirtualThreads.getDefaultVirtualThreadsExecutor());.

The Jetty team has provided another factory method, making it possible to supply a name prefix for virtual threads: https://github.com/jetty/jetty.project/issues/11353#issuecomment-1937053955

Looking into the codebase of the supplied Jetty, this new factory method seems to be available to Spring Boot already.

My suggestion would be to use this new factory method and assign either a default or a configurable virtual thread name prefix from the Jetty auto configuration (or both 😬).

At least the logged thread name should not be empty when using virtual threads.

scottfrederick commented 7 months ago

The new method is available starting with Jetty 12.0.7, which Spring Boot is using as of version 3.2.4.

Spring Boot typically hard-codes a thread name prefix (for example, see https://github.com/spring-projects/spring-boot/issues/39748) but does not make the prefix configurable. I think that should be sufficient here also.

holgerstolzenberg commented 7 months ago

I am totally fine with a hard coded thread name. Any chance this enhancement will make it to Spring Boot?

philwebb commented 7 months ago

@holgerstolzenberg This one has been marked as a bug and it has a 3.2.x target. That means it's something we'd like to fix in a 3.2 release if possible.

mhalbritter commented 7 months ago

@holgerstolzenberg The fix will be released in 3.2.5 on 2024-04-18.