On 30/09/2019 14:12, Rémy Maucherat wrote: <snip/>
> I added debug code in > AbstractProtocol.ConnectionHandler.release(SocketWrapperBase<S>) to check > if the processor considered was present in the waitingProcessors map. The > result is the following: > TEST-javax.servlet.http.TestHttpServletResponseSendError.NIO.txt:CHECK > PROCESSOR FAILED org.apache.coyote.http11.Http11Processor@77b16580 > TEST-javax.servlet.http.TestHttpServletResponseSendError.NIO.txt:CHECK > PROCESSOR FAILED org.apache.coyote.http11.Http11Processor@1d902704 > TEST-javax.servlet.http.TestHttpServletResponseSendError.NIO.txt:CHECK > PROCESSOR FAILED org.apache.coyote.http11.Http11Processor@610c4fc8 > TEST-javax.servlet.http.TestHttpServletResponseSendError.NIO.txt:CHECK > PROCESSOR FAILED org.apache.coyote.http11.Http11Processor@1a3a3cb6 > TEST-javax.servlet.http.TestHttpServletResponseSendError.NIO.txt:CHECK > PROCESSOR FAILED org.apache.coyote.http11.Http11Processor@336f552d > TEST-javax.servlet.http.TestHttpServletResponseSendError.NIO.txt:CHECK > PROCESSOR FAILED org.apache.coyote.http11.Http11Processor@3cd94f25 > TEST-javax.servlet.http.TestHttpServletResponseSendError.NIO.txt:CHECK > PROCESSOR FAILED org.apache.coyote.http11.Http11Processor@66e24762 > TEST-javax.servlet.http.TestHttpServletResponseSendError.NIO.txt:CHECK > PROCESSOR FAILED org.apache.coyote.http11.Http11Processor@7c7a1c3c > TEST-org.apache.coyote.http11.TestHttp11Processor.NIO.txt:CHECK PROCESSOR > FAILED org.apache.coyote.http11.Http11Processor@55a44822 > TEST-org.apache.coyote.http11.upgrade.TestUpgradeInternalHandler.NIO.txt:CHECK > PROCESSOR FAILED > org.apache.coyote.http11.upgrade.UpgradeProcessorInternal@6e55ff60 > TEST-org.apache.coyote.http11.upgrade.TestUpgrade.NIO.txt:CHECK PROCESSOR > FAILED org.apache.coyote.http11.upgrade.UpgradeProcessorExternal@37d98b7f > TEST-org.apache.tomcat.websocket.server.TestShutdown.NIO.txt:CHECK > PROCESSOR FAILED > org.apache.coyote.http11.upgrade.UpgradeProcessorInternal@6be9bd85 > TEST-org.apache.tomcat.websocket.TestWsRemoteEndpoint.NIO.txt:CHECK > PROCESSOR FAILED > org.apache.coyote.http11.upgrade.UpgradeProcessorInternal@3bd4e02f > TEST-org.apache.tomcat.websocket.TestWsRemoteEndpoint.NIO.txt:CHECK > PROCESSOR FAILED > org.apache.coyote.http11.upgrade.UpgradeProcessorInternal@4bb23a77 > TEST-org.apache.tomcat.websocket.TestWsRemoteEndpoint.NIO.txt:CHECK > PROCESSOR FAILED > org.apache.coyote.http11.upgrade.UpgradeProcessorInternal@32e20d65 > TEST-org.apache.tomcat.websocket.TestWsRemoteEndpoint.NIO.txt:CHECK > PROCESSOR FAILED > org.apache.coyote.http11.upgrade.UpgradeProcessorInternal@16abf52f > > All instances of not removed processors are either from async or upgraded > processors (the internal kind), as expected. I have verified the processor > instances above are never removed so it might be more robust to simply call > proto.removeWaitingProcessor(processor); in > AbstractProtocol.ConnectionHandler.release(SocketWrapperBase<S>) (after all > the socket is closed and done after that point). There could be a more fine > grained solution of course. > > However, this does not match the leak scenario described by the user, this > doesn't happen without async or websockets being used. I'm not sure those are leaks. I've started to check them and it looks like Tomcat is shutting down while an async request is still waiting to timeout. In those circumstances you would expect to see a Processor in waiting processors. A separate question is what is the correct error handling for async requests. There was some discussion on that topic on the Jakarta Servlet list but it didn't reach any definitive conclusions. I have some patches I need to get back to that should help but they are still a work in progress. I'll keep checking but my sense is that we haven't found the root cause of this leak yet. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
