Spinning off this specific topic.
On 08/10/2024 13:25, Rémy Maucherat wrote:
On Tue, Oct 8, 2024 at 7:51 AM Christopher Schultz
<ch...@christopherschultz.net> wrote:
In the pub track at the end of the day, I proposed bringing back the BIO
connector with Virtual Threads as the magic which makes everything work.
markt is convinced the idea has merit and on initial hand-waving
conversation, he thinks that maybe just maybe Tomcat 12 could dump both
NIO and NIO2 connectors, the Poller and other complexities. Servlet
async and Websocket both seem to have solutions based upon BIO and VT.
The question is whether or not VT will reach the level of maturity
required for Tomcat and downstream users to rely on it for production
workloads. Our initial sense is that yes, the promises of VT will be
realized in the timeframe during which Tomcat 12 will become stable.
This still looks difficult to me, as native code support cannot be
fixed. Of course polling is complex but it works. I don't expect this
to change, so VT would remain a niche use. Is there anything new that
changes this ?
The only thing that has changed is more thinking.
Back when I was trying to implement WebSocket on top of the Servlet API,
the reason I kept hitting deadlocks was that I was only using container
threads allocated in response to poller events. Even when we relaxed the
rule to one thread per request/response to one read thread and one write
thread per request/response deadlocks were still possible.
I haven't fully thought this through but I got as far as thinking it
could be worth experimenting with was something along the following lines:
- for blocking IO use virtual threads the same way we currently use
platform threads
- for a non-blocking read/write start a virtual thread to do the
read/write that executes the completion handler (or Future) code when
the read/write completes or fails
- we'd need a simple state machine for Servlet non-blocking IO to ensure
isReady() returned the correct value and that there were no more than
one non-blocking read and one non-blocking write in progress at the
same time
I haven't thought very much about WebSocket or h2 but I think there is
the potential to make both of the simpler to implement.
The plan didn't get much further than start a branch for the
refactoring, see how it goes and if it looks like it might work as for
more feedback at that point.
What was the concern around native code? That it pins the platform
thread? That should be OK if we are only using OpenSSL for operations we
don't expect to block like encryption.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
