Revisions to Spring Boot application gets stuck when virtual threads are used on Java 21

added 64 characters in body

edited Aug 2, 2024 at 9:48

4.6k
4
20
51

P.S. As @silverfox@silverfox pointed out

Apache HttpComponents Client 5.4-beta1 is released, and Compatibilitycompatible with Java Virtual Threads and Java 21 Runtime.

added 533 characters in body

Source Link

edited Aug 2, 2024 at 8:15

Sergey Tsypanov

4.6k
4
20
51

P.S. As @silverfox pointed out

Apache HttpComponents Client 5.4-beta1 is released, and Compatibility with Java Virtual Threads and Java 21 Runtime.

P.S.S. Another work-around is inflation of Tomcat's ForkJoinPool, see Can I configure parallelism of ForkJoinPool created for Tomcat in Spring Boot application?. Pay attention, that setting bigger number of connections won't help.

P.S.S.S. Java 24 is likely to be released in March 2025 and this would be the final solution for this issue.

added 114 characters in body

Source Link

edited Jul 31, 2024 at 8:12

Sergey Tsypanov

4.6k
4
20
51

The pool can be instantiated only with~~The pool can be instantiated only with maxTotal = 20 (maximum number of connections), to me it's a bug, but anyway,~~ By default maxTotal = 20ForkJoinPool of Tomcat is constructed with parallelism (maximum number of connectionsi.e. carrier thread count), to me it's a bug, but anyway 20, so let's verify whether the application will survive with smaller number of connections. In StuckApplicationTest we reduce the number of threads down to 20 and indeed the tests does not hang any more even having virtual threads enabled on the server side.

The pool can be instantiated only with maxTotal = 20 (maximum number of connections), to me it's a bug, but anyway, let's verify whether the application will survive with smaller number of connections. In StuckApplicationTest we reduce the number of threads down to 20 and indeed the tests does not hang any more even having virtual threads enabled on the server side.

~~The pool can be instantiated only with maxTotal = 20 (maximum number of connections), to me it's a bug, but anyway,~~ By default ForkJoinPool of Tomcat is constructed with parallelism (i.e. carrier thread count) 20, so let's verify whether the application will survive with smaller number of connections. In StuckApplicationTest we reduce the number of threads down to 20 and indeed the tests does not hang any more even having virtual threads enabled on the server side.