Hi,

With the release of Spring Boot 3.2 a new property spring.threads.virtual.enabled was added which, amongst other classes, configured Tomcat and Jetty HTTP request handling to be performed using a virtual thread executor.

Are there any plans to also provide out of the box support for Undertow?

Comment From: philwebb

I believe we may have looked into it but couldn't find the same kind of virtual thread support that Tomcat and Jetty were offering. @g-dx Have you seen any examples of how to configure Undertow to make use of virtual threads?

Comment From: ChunMengLu

@philwebb @g-dx How about this:

@Bean
public UndertowDeploymentInfoCustomizer undertowDeploymentInfoCustomizer() {
 return deploymentInfo -> deploymentInfo.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
}

Comment From: wilkinsona

Thanks, @ChunMengLu. We'll look at doing this automatically in Spring Boot 3.3.

Comment From: JavaLionLi

I just want to know why there is no support for 3.2, but instead support was provided in 3.3. Is there any downside

Comment From: mhalbritter

As discovered in https://github.com/spring-projects/spring-boot/issues/39812, the approach with the executor doesn't work, as it leaks memory. I had to revert the change.

Comment From: dheeraj29

Seems like memory issue is partially solved with https://issues.redhat.com/browse/UNDERTOW-2309 in 2.3.11 but still there is one open bug which occured with above release and tracked under https://issues.redhat.com/browse/UNDERTOW-2389

Once UNDERTWO-2389 is fixed, maybe virtual threads can be re-tested.

Comment From: philwebb

https://github.com/spring-projects/spring-boot/issues/39812#issuecomment-2187740426 has noted that both undertow issues are now fixed.

Comment From: mhalbritter

Yes, this now looks good. I've run some tests with virtual threads enabled and -Xmx256M. I don't see any exceptions in the log, the plot looks okay and the request rate is reasonable, too.

virtual-xmx-256


Summary:
  Total:    30.0004 secs
  Slowest:  0.1469 secs
  Fastest:  0.0000 secs
  Average:  0.0015 secs
  Requests/sec: 123590.2974

  Total data:   111221646 bytes
  Size/request: 111 bytes

Response time histogram:
  0.000 [1] |
  0.015 [995518]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.029 [3175]  |
  0.044 [853]   |
  0.059 [217]   |
  0.073 [118]   |
  0.088 [68]    |
  0.103 [0] |
  0.118 [0] |
  0.132 [0] |
  0.147 [50]    |


Latency distribution:
  10% in 0.0001 secs
  25% in 0.0001 secs
  50% in 0.0002 secs
  75% in 0.0003 secs
  90% in 0.0006 secs
  95% in 0.0009 secs
  99% in 0.0034 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0000 secs, 0.0000 secs, 0.1469 secs
  DNS-lookup:   0.0000 secs, 0.0000 secs, 0.0004 secs
  req write:    0.0000 secs, 0.0000 secs, 0.0031 secs
  resp wait:    0.0012 secs, 0.0000 secs, 0.1466 secs
  resp read:    0.0001 secs, 0.0000 secs, 0.0037 secs

Status code distribution:
  [200] 1000000 responses

Comment From: mhalbritter

We need to wait for an Undertow version which has the fix for https://issues.redhat.com/browse/UNDERTOW-2420 in it.

Comment From: mhalbritter

We have decided to ignore UNDERTOW-2420 and have upgraded the Undertow version in https://github.com/spring-projects/spring-boot/issues/42302 - so this issue can be tackled now.