On 21/02/2011 17:33, Tim Funk wrote: > Do you want to limit the try/catch scope to just > serverSocketFactory.acceptSocket since setSocketOptions() can also throw > IOException?
A couple of people have mentioned this and while the current code would be OK with a broader try/catch I like the idea of a limited try/catch since that makes it obvious what the code is doing. > Is there a case where a client can induce an exception while > setSocketOptions() is processing? I don't think so but let's not give them the opportunity. In terms of making this configurable, I'm minded not to initially. We can always add configuration options if users request them later. Mark > > > -Tim > > On 2/21/2011 10:21 AM, Mark Thomas wrote: >> The ASF Sonar installation managed to generate 46GB of identical log >> messages [1] today in the 8 hours it took to notice it was down. >> >> While better monitoring would/should have identified the problem sooner, >> it does demonstrate a problem with the acceptor threads in all three >> endpoints. If there is a system-level issue that causes the accept() >> call to always fail (such as hitting the ulimit) then the endpoint >> essentially enters a loop where it logs an error message for every >> iteration of the loop. This will result in many log messages per second. >> >> I'd like to do something about this. I was thinking of something along >> the lines of the following for each endpoint. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
