https://issues.apache.org/bugzilla/show_bug.cgi?id=56399
--- Comment #4 from Konstantin Kolinko <knst.koli...@gmail.com> --- (In reply to Remy Maucherat from comment #3) > The commit could be improved (besides trying to identify the problem with > the test): > - no apparent benefit of logging a stacktrace since it does not give any > additional info; if this is done for visibility in logs then I disagree with > that trick The goal here is to protect against unexpected bugs in request handling, as leaking unrecycled request or response has rather bad consequences. The stack trace is needed for us to identify problem code, as there are a dozen of ways in how processor recycling can be triggered. I expect such bugs to be rare and hard to reproduce, thus a stack trace is helpful. As the original cause of the problem is not some condition under administrator's control, but rather some problem in Tomcat code, I agree that using "warning" log level here is a nuisance. That is my fault. I will reduce the logging level to "info". It can be further reduced by help of UserDataHelper, but that strikes me as premature optimization. > - checking the request should be enough (although I would like to get info > if this is meant to try to detect bad async access too, in which case > checking the response commit state is a good idea) The request check can be simplified to check getHost() only. It essentially means that request line has been read and request has been run through Mapper. The response check essentially means that response.outputbuffer has not been recycled. The call returns a sum of two counters. In general request check should be enough. If request check was OK but response one fails, then maybe a) mapping failed (host==null), but some response was written. b) some broken webapp is still holding a reference to response object and is writing some data. As b) is more likely, maybe the response check fail should be treated differently, as it is likely a problem in web application code, not in Tomcat. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
