Re: Virtual Threads
On 05/09/2023 22:02, Christopher Schultz wrote: Mark, On 9/5/23 15:55, Mark Thomas wrote: On 05/09/2023 20:38, Christopher Schultz wrote: All, I have some questions about Virtual Threads and their use within Tomcat. Note that only Tomcat 11 currently has support for Virtual Threads when running on a version 19 or later JVM. Not quite. All current versions support virtual threads when running on Java 21 or later. Thanks for the correction. I just did a quick docs[1] search for "virtual" in Tomcat 10.x for example and I didn't see useVirtualThreads, so I assumed it wasn't in there. Maybe we need some documentation back-ports? Odd. It is there as an attribute on the Connector. And in 9.0.x and 8.5.x too. The virtual thread scheduler uses a work stealing queue so it isn't quite FIFO. That sounds like nit-picking to me. It is, but it is nit-picking for a reason. Violetta did some testing which showed switching to virtual threads showed a small (about 1%) throughput improvement it also showed a much broader spread of latencies. That increase in spread is due to the work-stealing queue. For those users watch latency carefully, the change was viewed as a significant drawback of switching to virtual threads. I think you have summed things up pretty well. I don't see a way with the current API to specify multiple virtual thread schedulers (which is what I think you would need to address this). Yeah, in all of the coverage I've seen online, there are no examples where Virtual Threads are used with an "executor" other than one that (a) accepts Runnable tasks and (b) just generates a Virtual Thread from that task which appears to be "bound" to the build-in default JVM-wide Virtual Thread executor. It would be potentially interesting to see an API which would allow different Executors to be used with Virtual Threads, even though the whole point of the entire thing is to avoid the (application-level) complexity of a thread pool/executor/etc. I think it does make sense, however, to be able to prioritize your threads a little bit. I haven't read anything about Virtual Threads and their priorities, so I assume it's just not part of anything user-facing at this point. I haven't seen anything that suggests that there will be any such API but to be fair, I haven't been following the Loom project that closely. For those of you that are finding this topic interesting, I'll have a talk on this at the ASF conference, Community Over Code in Halifax. https://communityovercode.org/schedule-list/#TH001 More broadly, there are usually a reasonable number of Tomcat committers present at ASF conferences so this is a great opportunity to speak face to face with the committers. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CVE referencing Tomcat are not also referencing Tomcat-embed
Hello, I'm in the process of switching from Dependency-check [1] to Dependency-track [2] to analyse vulnerabilities on my dependencies. I analyze a classic spring boot webapp depending upon org.apache.tomcat.embed:tomcat-embed-core. Dependency Check who uses a kind of fuzzy logic detects (correctly ?) CVEs (such as CVE-2023-28709 or CVE-2023-41080). Dependency-track uses exact matching with the artifact identifiers and does not detect those CVE. I imagine (not totally sure) that those CVE are also affecting tomcat-embed-core and not only apache:tomcat, but it seems like they are not targeting this "by product" of the classic Tomcat. What is or should be the correct process ? Should the Tomcat team declare those CVE as also affecting tomcat-embed-core ? Should the CVE people do the job by themselves ? I've just found out that I'm not the only one having those questions: https://stackoverflow.com/questions/74886946/vulnerablities-for-tomcat-embed-core-in-owasp-dependencytrack but still looking for advice/guidance. Best regards Francois [1] - https://owasp.org/www-project-dependency-check/ [2] - https://dependencytrack.org/
Re: CVE referencing Tomcat are not also referencing Tomcat-embed
On 06/09/2023 20:04, Francois Marot wrote: Hello, I'm in the process of switching from Dependency-check [1] to Dependency-track [2] to analyse vulnerabilities on my dependencies. I analyze a classic spring boot webapp depending upon org.apache.tomcat.embed:tomcat-embed-core. Dependency Check who uses a kind of fuzzy logic detects (correctly ?) CVEs (such as CVE-2023-28709 or CVE-2023-41080). Dependency-track uses exact matching with the artifact identifiers and does not detect those CVE. I imagine (not totally sure) that those CVE are also affecting tomcat-embed-core and not only apache:tomcat, but it seems like they are not targeting this "by product" of the classic Tomcat. What is or should be the correct process ? Should the Tomcat team declare those CVE as also affecting tomcat-embed-core ? Should the CVE people do the job by themselves ? The Tomcat project maps CVEs to Tomcat versions. We do not break it down to the component level. You need to raise this with whichever entity is mapping the Tomcat CVEs to specific components rather than all components for that version. It looks like dependency track should be you first point of call. Mark I've just found out that I'm not the only one having those questions: https://stackoverflow.com/questions/74886946/vulnerablities-for-tomcat-embed-core-in-owasp-dependencytrack but still looking for advice/guidance. Best regards Francois [1] - https://owasp.org/www-project-dependency-check/ [2] - https://dependencytrack.org/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Virtual Thread Configuration In Tomcat 11
William, On 9/5/23 17:41, William Crowell wrote: Great post earlier today! This is a super interesting topic to me. You can find the performance testing results located here: http://ec2-18-188-185-212.us-east-2.compute.amazonaws.com:8080/web-report/ I did 10 runs with 1000 threads with a ramp up time of 3 seconds for a duration of 200 seconds. Ignore the 11th run. This is a really simple REST application with Spring. It just makes an insert into a MySQL table. When I get a moment I will put my code into GitHub, but again, there is not much to it. You can find a very similar Spring Boot example with embedded Tomcat here: https://medium.com/@anil.java.story/embracing-virtual-threads-in-spring-boot-4140d3b8a5a But he uses JDK 20 with --enable-preview turned on. The mistake I think I made was that the inserts are not really blocking because they happen so quickly. Maybe because I did not put enough load in the test? I have no synchronized blocks in my code. So, it appeared to me that the inserts were taking twice the amount of time with virtual threads. I think that extra time is just overhead of pinning virtual threads to a platform thread and managing the ForkJoinPool. What is going to happen is that people are going to “flip the switch”…useVirtualThreads=”true”. They will find that performance will not be as good as using an operating system thread and abandon virtual threads because their code does not block. So, I need to come up with an example where my code blocks and redo the perf test and prove this out. I don’t know. Try setting this system property before running your tests and see if it produces any output on the server while the load test is running: -Djdk.tracePinnedThreads=full -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Virtual Threads
Mark, On 9/6/23 03:29, Mark Thomas wrote: On 05/09/2023 22:02, Christopher Schultz wrote: Mark, On 9/5/23 15:55, Mark Thomas wrote: On 05/09/2023 20:38, Christopher Schultz wrote: All, I have some questions about Virtual Threads and their use within Tomcat. Note that only Tomcat 11 currently has support for Virtual Threads when running on a version 19 or later JVM. Not quite. All current versions support virtual threads when running on Java 21 or later. Thanks for the correction. I just did a quick docs[1] search for "virtual" in Tomcat 10.x for example and I didn't see useVirtualThreads, so I assumed it wasn't in there. Maybe we need some documentation back-ports? Odd. It is there as an attribute on the Connector. And in 9.0.x and 8.5.x too. https://tomcat.apache.org/tomcat-10.0-doc/config/executor.html I don't find the word "virtual" anywhere on that page. The virtual thread scheduler uses a work stealing queue so it isn't quite FIFO. That sounds like nit-picking to me. It is, but it is nit-picking for a reason. Violetta did some testing which showed switching to virtual threads showed a small (about 1%) throughput improvement it also showed a much broader spread of latencies. That increase in spread is due to the work-stealing queue. For those users watch latency carefully, the change was viewed as a significant drawback of switching to virtual threads. That's a significant point, thanks for reiterating it. I think you have summed things up pretty well. I don't see a way with the current API to specify multiple virtual thread schedulers (which is what I think you would need to address this). Yeah, in all of the coverage I've seen online, there are no examples where Virtual Threads are used with an "executor" other than one that (a) accepts Runnable tasks and (b) just generates a Virtual Thread from that task which appears to be "bound" to the build-in default JVM-wide Virtual Thread executor. It would be potentially interesting to see an API which would allow different Executors to be used with Virtual Threads, even though the whole point of the entire thing is to avoid the (application-level) complexity of a thread pool/executor/etc. I think it does make sense, however, to be able to prioritize your threads a little bit. I haven't read anything about Virtual Threads and their priorities, so I assume it's just not part of anything user-facing at this point. I haven't seen anything that suggests that there will be any such API but to be fair, I haven't been following the Loom project that closely. For those of you that are finding this topic interesting, I'll have a talk on this at the ASF conference, Community Over Code in Halifax. https://communityovercode.org/schedule-list/#TH001 More broadly, there are usually a reasonable number of Tomcat committers present at ASF conferences so this is a great opportunity to speak face to face with the committers. +1 -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Virtual Threads
On 06/09/2023 21:24, Christopher Schultz wrote: On 9/6/23 03:29, Mark Thomas wrote: On 05/09/2023 22:02, Christopher Schultz wrote: Thanks for the correction. I just did a quick docs[1] search for "virtual" in Tomcat 10.x for example and I didn't see useVirtualThreads, so I assumed it wasn't in there. Maybe we need some documentation back-ports? Odd. It is there as an attribute on the Connector. And in 9.0.x and 8.5.x too. https://tomcat.apache.org/tomcat-10.0-doc/config/executor.html I don't find the word "virtual" anywhere on that page. It is a Connector attribute, not an Executor attribute. There isn't much point using an executor with virtual threads. For those of you that are finding this topic interesting, I'll have a talk on this at the ASF conference, Community Over Code in Halifax. https://communityovercode.org/schedule-list/#TH001 More broadly, there are usually a reasonable number of Tomcat committers present at ASF conferences so this is a great opportunity to speak face to face with the committers. +1 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
java.lang.ClassNotFoundException for listener class
Hello all. I have developed a web application using Eclipse as an IDE and test environment and it runs as expected. Then I have built a war file and deployed it under another Tomcat instance. In both case tomcat version is 8.5 Under this last instance the application can't start and in the log files I find: 07-Sep-2023 07:48:18.173 SEVERE [http-nio-8080-exec-129] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class [it.archimede.met.obliterazione.zse.servlet.CreaConnessione] java.lang.ClassNotFoundException: it.archimede.met.obliterazione.zse.servlet.CreaConnessione at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1358) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1180) at org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:545) at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:526) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:150) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4613) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5155) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:614) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:486) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1634) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:607) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:286) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1562) at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:990) at org.apache.catalina.manager.HTMLManagerServlet.deployInternal(HTMLManagerServlet.java:320) at org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:209) at javax.servlet.http.HttpServlet.service(HttpServlet.java:652) at javax.servlet.http.HttpServlet.service(HttpServlet.java:733) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:211) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:668) at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:348) at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:52) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) at org.apache.c
