THALES GROUP LIMITED DISTRIBUTION to email recipients
Hello Christopher,
Just to be sure ...
For HTTP/1.1 request traffic and virtual thread usage, your recommendation is:
- Executor declaration in server.xml like:
<Executor name="virtualThread"
className="org.apache.catalina.core.StandardVirtualThreadExecutor" />
- Connector declaration in server.xml like:
<Connector executor="virtualThread" port="8080"
protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="8443"
maxParameterCount="1000">
</Connector>
instead of this connector only declaration like:
<Connector port="8080"
protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="8443"
maxParameterCount="1000"
useVirtualThreads="true"> ==> create a executor
where the className is set to org.apache.catalina.core.StandardVirtualThreadExecutor
</Connector>
or like:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
maxParameterCount="1000"
useVirtualThreads="true" /> ==> create a executor
where the className is set to org.apache.catalina.core.StandardVirtualThreadExecutor
Is my understanding of your recommendation correct ?
-----Original Message-----
From: Christopher Schultz <[email protected]>
Sent: lundi 3 novembre 2025 20:08
To: [email protected]
Subject: Re: Tomcat 10 and virtual thread
Francois,
On 11/3/25 1:39 PM, COURTAULT Francois wrote:
I am confused because the way (see underneath) I configured initially seems OK:
it triggers the virtual thread usage. Indeed I am able to see
ForkJoinPool-1-worker-1 😊 in the thread dump I triggered
* first, declare an executor in server.xml like below
<Executor name="virtualThread"
className="org.apache.catalina.core.StandardVirtualThreadExecutor" />
* second, use a connector which will refer this above Executor thanks to
its name attribute.
The way I do it, is to update line 74, in server.xml, from <Connector
port="8080" protocol="HTTP/1.1" to
<Connector executor="virtualThread" port="8080" protocol="HTTP/1.1"
If now I look at
https://tomcat.apache.org/tomcat-10.1-doc/config/http.html
The useVirtualThreads attribute is listed under the Standard Implementation
section which talks about standard HTTP connectors (NIO and NIO2).
So we should only use for protocol attribute one of the following
Http11NioProtocol and Http11Nio2Protocol protocols.
In your configuration, you don't use one of these above protocols.
Why having several ways to enable virtual threads usage ?
This is historical. Tomcat used to support only <Connector> and then <Executor> was introduced, later.
In order to support backward-compatible (and simpler) configurations, <Connector> will create an
<Executor> if the <Connector> does not specify an <Executor>.
So, what is the recommended configuration, for using virtual thread, to use ?
- Define a new Executor with StandardVirtualThreadExecutor as a className
attribute
Define a connector on HTTP protocol with an executor attribute set to
the name of the new Executor
- Or
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" or
"org.apache.coyote.http11.Http11Nio2Protocol"
connectionTimeout="20000"
redirectPort="8443"
maxParameterCount="1000"
useVirtualThreads="true">
</Connector>
BTW for HTTP1.0/1.1 traffic with no TLS what Connector should we use ?
- <Connector port="8080" protocol="HTTP/1.1"
- or <Connector port="8080" protocol="
org.apache.coyote.http11.Http11NioProtocol"
- or <Connector port="8080" protocol="
org.apache.coyote.http11.Http11Nio2Protocol"
I would recommend <Connector> + <Executor> because <Executor> supports more configuration
options for the executor itself than <Connector> does. For example, configuring an <Executor>
explicitly allows you to have a thread-pool whose connections can be retired after inactivity.
(That doesn't matter at all for Virtual Threads, as the thread pool itself is
essentially always empty -- no threads are ever re-used.)
If you are looking for unrelated recommendations, I would also use NIO instead
of NIO2. NIO has far more usage in the real world than NIO2.
NIO2 uses a different I/O model which was supposed to be much faster than NIO,
but then NIO improved significantly and the promises of NIO2 were realized by
NIO. *shrug*
-chris
-----Original Message-----
From: William Crowell <[email protected]>
Sent: lundi 3 novembre 2025 17:15
To: Tomcat Users List <[email protected]>
Subject: Re: Tomcat 10 and virtual thread
Hi,
I have never tried doing it through the executor like that. How I enable
virtual threads in server.xml is like this:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
maxParameterCount="1000"
useVirtualThreads="true" />
You should be using at least JDK21 for that to work. When you do a thread dump
you will see virtual threads in the dump.
Extra info FYI: Running with JVM argument -Djdk.tracePinnedThreads=full prints
a complete stack trace when a thread blocks while pinned, with the native
frames and frames holding monitors highlighted. Running with
-Djdk.tracePinnedThreads=short limits the output to just the problematic frames:
Thread[#41,ForkJoinPool-1-worker-4,5,CarrierThreads]
com.mysql.cj.jdbc.ConnectionImpl.isValid(ConnectionImpl.java:2516) <==
monitors:1 Thread[#39,ForkJoinPool-1-worker-2,5,CarrierThreads]
com.mysql.cj.jdbc.ConnectionImpl.isValid(ConnectionImpl.java:2516) <==
monitors:1 Thread[#41,ForkJoinPool-1-worker-4,5,CarrierThreads]
com.mysql.cj.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:2005)
<== monitors:1 Thread[#43,ForkJoinPool-1-worker-5,5,CarrierThreads]
com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:893)
<== monitors:1
com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1061)
<== monitors:1
com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1009)
<== monitors:1 Thread[#43,ForkJoinPool-1-worker-5,5,CarrierThreads]
com.mysql.cj.jdbc.ConnectionImpl.commit(ConnectionImpl.java:791) <==
monitors:1 Thread[#43,ForkJoinPool-1-worker-5,5,CarrierThreads]
com.mysql.cj.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:200
5) <== monitors:1
Regards,
William Crowell
From: COURTAULT Francois <[email protected]>
Date: Monday, November 3, 2025 at 11:05 AM
To: [email protected] <[email protected]>
Subject: Tomcat 10 and virtual thread
[You don't often get email from
[email protected]. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
THALES GROUP LIMITED DISTRIBUTION to email recipients
Hello everyone,
Looking at https://tomcat.apache.org/tomcat-10.1-doc/config/executor.html we
can configure Tomcat 10.1.x to use virtual threads instead of platform threads.
Do you confirm ?
The way to do it, as far as I understood, is to:
* first, declare an executor in server.xml like below
<Executor name="virtualThread"
className="org.apache.catalina.core.StandardVirtualThreadExecutor" />
* second, use a connector which will refer this above Executor thanks to
its name attribute.
The way I do it, is to update line 74, in server.xml, from <Connector port="8080"
protocol="HTTP/1.1" to
<Connector executor="virtualThread" port="8080" protocol="HTTP/1.1"
I started Tomcat and triggered a thread dump.
I was not able to see any tomcat-virt string.
Does it mean that the virtual thread usage is still disabled ?
What's wrong with my configuration ?
Best Regards.
CAUTION: This email originated from outside of the organization. Do not click
on links or open attachments unless you recognize the sender and know the
content is safe.
This e-mail may contain information that is privileged or confidential. If you
are not the intended recipient, please delete the e-mail and any attachments
and notify us immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
