rmaucher commented on pull request #371: URL: https://github.com/apache/tomcat/pull/371#issuecomment-718632321
maxConnections overall is a bad design for NIO2, that is a bit obvious. It started with connections not being counted accurately then after some iterative refactorings of close it remains a bad idea. For the longest time the default was fixed to -1 (still there in 8.5). I guess all you're doing is add a heuristic that works for you [but actually no guarantee]. Also about accept, I refactored it NIO2 style to save one thread and it seems more efficient overall, before it was a much more classical NIO1 style accept using the same dedicated thread (so one extra thread, and likely less efficient). The downside of the strategy is that the accept is just like the other processing threads when maxConnections is used. If there's a heavy thread starvation, then accept will get delayed. I don't think it's the end of the world, the server will actually be slow for everyone, but I understand. OTOH, if your app is as you say using non blocking IO and is saving on threads, then there's no downside to the strategy [even with full use of the thread pool, the threads become available very frequently and accept stays responsive]. So I'm ok with adding some heuristic, but maxThreads can be too low. Maybe maxConnections/2 would be good enough, with another heuristic on a minimal number ... Not very clean ... ---------------------------------------------------------------- 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. 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
