On 05/06/17 09:38, Violeta Georgieva wrote: <snip/>
> Try with this test > https://github.com/violetagg/tomcat/commit/53564d4e73496cb3badcaaab81a1314cf2ed750d Thanks. That clarifies things a lot. It boils down to what should happen when an I/O error occurs reading from the request or writing to the response on an non-container thread. The Servlet spec is silent on the issue. There are some requirements starting with the last bullet at the bottom of page 2-16 of the final 3.1 specification but they relate to errors during the call to dispatch. Tomcat's current behaviour is to: - rethrow the exception so it is visible to the non-container thread - expect the non-container thread to exit without further I/O or calls to the async API - invoke the async error handling mechanism that will in turn call complete() or dispatch() Also, the reason this is the way it is is to ensure that when there is an I/O error, the correct clean-up is performed by the container (e.g. correctly tracking the current connection count). The problem in the test case occurs when the non-container thread catches the error and calls dispatch before the invocation of the async error handling has taken effect. The lack of specification in this area is a real problem. If we leave it up to the non-container thread to do the clean-up, many won't. If we always have the container do the clean-up, it is likely to conflict with non-container threads that try to do the same. I'm currently on the fence between calling this an application error (the non-container thread should not call dispatch after an I/O error) and trying to figure out if there is a way we could handle this. I'm currently looking at the code to see what the options might be. Did you have a patch in mind? We also need to be careful that we don't end up with multiple container threads trying to handle the same async request. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
