Re: Trying to use Loom virtual threads with Tomcat

2022-05-09 Thread Cay Horstmann

Il 03/05/2022 08:31, Cay Horstmann ha scritto:

Il 03/05/2022 07:25, Rémy Maucherat ha scritto:
On Tue, May 3, 2022 at 6:24 AM Cay Horstmann  
wrote:


Hi, I am trying to experiment with Loom
(https://openjdk.java.net/jeps/425) virtual threads in Tomcat 10. There
is a nice extension point in server.xml where I can provide an Executor
and use it in the default Connector. It works like a charm--all my
requests run on a virtual thread, and AFAIK, nothing else does.

There is just one issue. It takes forever for Tomcat to execute the
virtual threads. I made a timestamp for each invocation of

public void execute(Runnable command)

called from org.apache.tomcat.util.net.AbstractEndpoint.processSocket

When I fire 1000 simultaneous requests, I can see that method being
invoked 1000 times, but it takes a while to work through the requests.
The last invocation occurs two minutes (!) from the sending of the 
requests.


When using the org.apache.catalina.core.StandardThreadExecutor, that
many requests are handled in 3 seconds.

Is there something that I am overlooking? I had hoped that execute would
be called near-instantly 1000 times, and then the Loom virtual threads
could show their mettle and execute concurrently.


I wanted to experiment with Loom, but most likely the current Tomcat
NIO(2) connector is not nice for that. I was thinking that
resurrecting the java.io code (actually: writing a new java.io
connector) could be a slightly better plan, but to be honest I don't
expect very good results. I wasn't planning to do it immediately since
Loom is so experimental right now.



I figured this out in the end. When using Nio2, changing the executor in 
server.xml doesn't seem useful. That executor is then used in the inner 
workings of the selector mechanism. That is probably not what anyone 
wants to do. But with Nio, plugging in Loom for running the servlet 
methods is very reasonable. There is only one issue. Loom cannot (yet) 
handle "synchronized".


Changing the synchronized block in 
org/apache/tomcat/util/net/SocketProcessorBase.run() to a ReentrantLock 
makes the Loom threads fly, with impressive performance.


Cheers,

Cay

--

Cay S. Horstmann | http://horstmann.com | mailto:c...@horstmann.com

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Trying to use Loom virtual threads with Tomcat

2022-05-03 Thread Cay Horstmann

Il 03/05/2022 07:25, Rémy Maucherat ha scritto:

On Tue, May 3, 2022 at 6:24 AM Cay Horstmann  wrote:


Hi, I am trying to experiment with Loom
(https://openjdk.java.net/jeps/425) virtual threads in Tomcat 10. There
is a nice extension point in server.xml where I can provide an Executor
and use it in the default Connector. It works like a charm--all my
requests run on a virtual thread, and AFAIK, nothing else does.

There is just one issue. It takes forever for Tomcat to execute the
virtual threads. I made a timestamp for each invocation of

public void execute(Runnable command)

called from org.apache.tomcat.util.net.AbstractEndpoint.processSocket

When I fire 1000 simultaneous requests, I can see that method being
invoked 1000 times, but it takes a while to work through the requests.
The last invocation occurs two minutes (!) from the sending of the requests.

When using the org.apache.catalina.core.StandardThreadExecutor, that
many requests are handled in 3 seconds.

Is there something that I am overlooking? I had hoped that execute would
be called near-instantly 1000 times, and then the Loom virtual threads
could show their mettle and execute concurrently.


I wanted to experiment with Loom, but most likely the current Tomcat
NIO(2) connector is not nice for that. I was thinking that
resurrecting the java.io code (actually: writing a new java.io
connector) could be a slightly better plan, but to be honest I don't
expect very good results. I wasn't planning to do it immediately since
Loom is so experimental right now.



Thanks for your fast response. I am wondering what issue you see with 
that connector. I am not changing the threading for the NIO part. Only 
when a socket is connected, a Loom thread is created.


I tried reading through the code of NioEndpoint/AbstractEndpoint (which 
I find on the call stack of the call to execute in my executor). I can't 
find anything that throttles the acceptance. I don't think that there 
would necessarily be a huge win with Loom, but I am baffled why it is 
doing so much worse.


Cheers,

Cay

--

Cay S. Horstmann | http://horstmann.com | mailto:c...@horstmann.com

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Trying to use Loom virtual threads with Tomcat

2022-05-02 Thread Cay Horstmann
Hi, I am trying to experiment with Loom 
(https://openjdk.java.net/jeps/425) virtual threads in Tomcat 10. There 
is a nice extension point in server.xml where I can provide an Executor 
and use it in the default Connector. It works like a charm--all my 
requests run on a virtual thread, and AFAIK, nothing else does.


There is just one issue. It takes forever for Tomcat to execute the 
virtual threads. I made a timestamp for each invocation of


public void execute(Runnable command)

called from org.apache.tomcat.util.net.AbstractEndpoint.processSocket

When I fire 1000 simultaneous requests, I can see that method being 
invoked 1000 times, but it takes a while to work through the requests. 
The last invocation occurs two minutes (!) from the sending of the requests.


When using the org.apache.catalina.core.StandardThreadExecutor, that 
many requests are handled in 3 seconds.


Is there something that I am overlooking? I had hoped that execute would 
be called near-instantly 1000 times, and then the Loom virtual threads 
could show their mettle and execute concurrently.


Thanks,

Cay

--

Cay S. Horstmann | http://horstmann.com | mailto:c...@horstmann.com

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org