mjgp2 commented on PR #612: URL: https://github.com/apache/tomcat/pull/612#issuecomment-1527404654
I can find this documentation on the `AsynchronousChannelGroup.withCachedThreadPool` call made within this websocket code: ``` • An asynchronous channel group associated with a cached thread pool submits events to the thread pool that simply invoke the user's completion handler. • Internal kernel's I/O operations are handled by one or more internal threads that are not visible to the user application. • That means you have one hidden thread pool that dispatch events to a cached thread pool, which in turn invokes completion handler • Probability of suffering the hangs problem as with the FixedThreadPool is lower. • Still might grows infinitely (those infinite thread pool should have never existed anyway!). • At least you guarantee that the kernel will be able to complete its I/O operations (like reading bytes). • Oups...CachedThreadPool must support unbounded queueing to works properly (grrr not sure I like that!!!). • So you can possibly lock all the threads and feed the queue forever until OOM happens. Great! • Of course, nobody will ever do that! ``` So in short this threadpool is only used for completion callbacks. It seems like the decision was made to have a synchronous queue with an unbounded number of threads, rather than have a bounded number of threads and an unbounded queue. To me this seems like the wrong way round, interested to hear thoughts? There is no good reason to keep the threads running forever that I can see based on the documentation and also other implementations that call the `withCachedThreadPool` method? Additionally, looking at the dump there are two `SecureIO` threads created for _every_ websocket session. This seems very resource hungry if you have hundreds of websocket connections? This is something that I imagine could be solved by virtual threads, or refactoring to have a shared thread pool? Thanks all [threaddump.txt](https://github.com/apache/tomcat/files/11352856/threaddump.txt) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
