Closed ceki closed 7 months ago
See commits 9a1fc44f84befa8f05eaeea3f236014a556872e2 and f6d690dfe85c96cfc00e23321c381122f266b5de
hi @ceki, How can I enable this virtual thread feature? Are there some documents?
@wupei93 it looks like it switches automatically when running under Java 21. The code by @ceki, however, seems to still contain System.out.println()
s, so I'm guessing it's not quite ready.
@johncurrier Indeed, the switch is automatic when running under Java 21.
The System.out.println() issue existed in 1.3.12/14.12 released on 2023-12-27 and was fixed a in version 1.3.13/1.4.13 released a day later. Are you observing otherwise?
I'm using logback 1.3.11 in my scala code (which is compiled by java 8) and just upgraded to logback 1.3.12. sbt compile failed with bad constant pool index
error and failed. compiler version is 2.13.10
Is there any dependency updates in 1.3.12 that could cause this?
In JDK 21.0.1 and 21.0.2 (tested on Eclipse Temurin distribution, without any -add-opens
flags) the code added in 9a1fc44 (ExecutorServiceUtil#makeThreadFactory
) fails with the following error:
java.lang.IllegalAccessException: class ch.qos.logback.core.util.ExecutorServiceUtil$1
cannot access a member of class java.lang.ThreadBuilders$VirtualThreadBuilder (in module java.base)
with modifiers "public"
and the DefaultThreadFactory
is used.
@mgocd In a JIGSAW modular application the IllegalAccessException
is thrown but caught and Executors.defaultThreadFactory()
is used. Would you concur?
@ceki Yes it's thrown, caught and Executors.defaultThreadFactory()
is used, but I observed it in a standard non-modularized Spring Boot app, please see a minimal reproduction here: https://github.com/mgocd/logback-virtualthreads
@mgocd The issue is unrelated to JIGSAW modularization but accessing a package private inner class via reflection. The IllegalAccessException
issue has been fixed in logback 1.5.0.
Investigate and implement support for virtual threads introduced in JDK 21.
Java documentation states:
Two difficulties were encountered while adding virtual threads in logback.
First, while Multi-Release Jar files make it easy to support JDK version dependent code in projects, support for support for Multi-Release jar files in IDEs when combined with build tools is lacking (as of 2023-11-25). When the Multi-Release path seemed blocked, the project reverted to the old practice of adding support via reflection.
Second, virtual threads are meant to be used for tasks which spend most of their time waiting for blocking I/O operations. Thus virtual threads are meant to reduce resource consumption which is not easy to measure and requires good judgement.