Le mer. 20 mars 2024 à 18:43, Rainer Jung <rainer.j...@kippdata.de> a écrit :
> Am 20.03.24 um 18:34 schrieb Romain Manni-Bucau: > > Hi Chris, > > > > Thread dumps being dump of threads - literally os threads - and virtual > > threads not being threads at all - they are runnables in a dedicated > thread > > pool - it is quite fair to not make them the same and have their > scheduler > > - pool - only in the thread dump but not themselves no? > > Similarly to why threadlocal are not recommended for virtual thread this > > would probably make an useless pressure on the JVM IMHO - why there is an > > option to see it but it is mainly for debug purposes. > > See virtual threads as continuations (suspendable/resumable "Runnable") > in > > a dedicated and not programmatically configurable nor > selectable/proviable > > thread pool, they are not in thread dumps and this doesnt bother you ;) - > > ultimately if you want it you want all java objects to be monitored and > in > > the thread dump which would be weird - but I agree the semantic is > > misleading. > > Nevertheless it would be helpful to knw, which virtual threads currently > have an associated OS thread or not, and for those having one, what > their stack is. And this not just as a dump into a file, but instead > available via a proper API. It might be worth to ask the JDK devs about > chanced to get such an API. > Hmm, I must miss something but virtual threads with an associated os thread are in the thread dump since they run code (execution is in a normal forkjoinpool). So if you lock - synchronized/mutex for ex issue - then you see it as before. That said for that they added a pinned system prop enabling to validate your app is VT friendly or not which is very helpful. > > From my tests virtual threads do their job but they stay slower than a > > proper reactive/async impl mainly due to the overhead they add > *everywhere* > > compare to reactive programming plus this single thread pool issue which > > adds a lot of contention when all the app/lot of tasks is/are done using > it > > - vs bulkhead pattern for ex. > > But if you come from a plain sync application it can be very interesting > if > > it stays compatible and you don't need to add throttling to control the > > memory - often in the old style you throttle with the number of threads, > > now you need a semaphore or alike. > > Will not be a free lunch ;). > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le mer. 20 mars 2024 à 18:20, Christopher Schultz < > > ch...@christopherschultz.net> a écrit : > > > >> Rainer, > >> > >> Thanks for writing this up. > >> > >> On 3/20/24 07:22, Rainer Jung wrote: > >>> I wanted to share an observation and I hope the things are correct how > I > >>> am describing them. Maybe things have already improved and I am not > >>> aware of it, hints welcome. > >>> > >>> Part of JEP 425 (Project Loom, Java virtual threads) discusses how to > >>> handle observability of virtual threads from inside the JVM and > tooling. > >>> > >>> The final outcome is, that virtual threads are not included in the > >>> typical JVM APIs which one can use to observe threads, like enumerating > >>> them or accessing the stacks of individual threads. As a consequence, > >>> also jstack and "kill -QUIT" do not show virtual threads at all, not > >>> even when they are attached to a native thread and executing code. > >> > >> O_O > >> > >>> There is one single method to help with observability of virtual > threads > >>> > >>> > >> > https://docs.oracle.com/en/java/javase/21/docs/api/jdk.management/com/sun/management/HotSpotDiagnosticMXBean.html#dumpThreads(java.lang.String,com.sun.management.HotSpotDiagnosticMXBean.ThreadDumpFormat) > >>> > >>> which dumps a full thread dump to a file. Of course that is by no means > >>> appropriate, if you want to do a fine grained observation. At least you > >>> can choose to write a json structure instead of a hard to parse text > >>> format, but that's it. > >> > >> Boy, that's a real miss from the JVM team. I'm surprised that they have > >> overlooked this. I don't see a real reason that a Virtual Thread would > >> be treated any differently than a regular thread. > >> > >>> For instance I am often using a tool, that inspects our > >>> RequestProcessors to find long running requests and then retrieves the > >>> list of Java threads as ThreadInfo objects to find the one executing > the > >>> request and finally retrieves the stack of that request from the JVM. > >>> Such an approach is no longer possible. Almost all of JMX does not show > >>> any info about virtual threads. > >>> > >>> It also seems Tomcat no longer uses a pool when a connector is > >>> configured to use virtual threads. So there are no metrics like > >>> currentThreadCount or currentThreadsBusy. > >> > >> When using virtual threads, the number of requests is the same as the > >> number of threads, since each request -> new Virtual Thread.... though I > >> think the request-count is only incremented when the request has > >> completed, so maybe there are threads running that can't be counted > (yet). > >> > >> But I understand that you were hoping to get some information about > >> these threads and though maybe Tomcat's metrics could help. I guess not > >> really. > >> > >> But thread-busy count is the same as in-flight-request count. And > >> current thread count is the same as in-flight-request count as well. > >> > >>> I guess this also limits the use of some manager features and probably > >>> also the StuckThreadsDetectionValve when combined with virtual threads. > >> > >> Most likely. I'm fairly sure that uses the "usual Thread-walker things" > >> which you are reporting do not work any more with VTs. > >> > >> What JVM are you using for your investigations? > >> > >>> Of course Tomcat has solved most of the problems, that virtual threads > >>> want to solve, by doing the hard work of using the NIO and NIO2 APIs. > So > >>> virtual threads are probably not that important for us. But we should > be > >>> aware of the observability deficiencies whenever we would discuss > >>> whether we could switch from NIO or NIO2 to virtual threads to simplify > >>> connector code in some distant future. > >> > >> +1 > >> > >> I've been enthusiastically talking with markt about dropping all that > >> nasty NIO stuff and "going back to BIO with virtual threads" which, at > >> this point, is mostly a threat and not a promise. But if VTs really > >> deliver everything they are claiming to deliver, then it may be possible > >> to go back to BIO as long as servlet-async is retired. And I'm not > >> holding my breath on that one. > >> > >> -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
