Hi, A long time ago (in this galaxy, not another one), Tomcat has added the capability to have multiple accept threads. I have no idea what test revealed that Tomcat was somehow not accepting sockets fast enough, and maybe it could be the case in crazy microbenchmarks, but this is not going to happen in the real world. If the server is too busy accepting, then what comes after the accept (SSL handshake maybe) is much worse and refusing sockets may be the most sensible behavior. Having multiple accept threads is also now a known antipattern. So I am proposing to hardcode acceptorThreadCount to 1 for all connectors.
Same for polling basically. Polling occurs once a socket waits for data or backlogs for about an eternity (in CPU time), so a single polling thread is more than enough to handle this in a responsive enough way (BTW, I am interested in current data that demonstrates a responsiveness benefit). Earlier in the past, with APR and plain old select (and Windows !!), it was probably way more justified to allow having multiple threads. So I am also proposing to hardcode pollerThreadCount to 1 for NIO. I will leave the feature in for APR, just in case. Note: NIO 2 works properly, yet uses no dedicated accept thread (accept is now an async task that restarts itself once done), and internally has one internal thread for polling and one internal thread for timeouts. So ... Comments ? Rémy
