On Mon, Jan 2, 2012 at 4:31 PM, Konstantin Kolinko <knst.koli...@gmail.com> wrote: > 2011/12/31 Janne Jalkanen <janne.jalka...@ecyrd.com>: >> Hi all! >> >> I am seeing odd behaviour with 7.0.23, with the tomcat user's open file >> count increasing slowly, but consistently. Two other instances running the >> exact same codebase on identical hardware, BUT with Tomcat 7.0.20, are not >> exhibiting the same behaviour. 7.0.20 is rock solid, 7.0.23 dies due to too >> many open files every now and then. I've increased ulimit for now, but this >> is still a bit nasty. >> >> Any suggestions where to look? Should I file a bug? >> >> lsof says >> >> ... >> java 21299 ubuntu 87r sock 0,6 0t0 31983006 >> can't identify protocol >> java 21299 ubuntu 88r sock 0,6 0t0 31983007 >> can't identify protocol >> java 21299 ubuntu 89r sock 0,6 0t0 31983008 >> can't identify protocol >> java 21299 ubuntu 90r sock 0,6 0t0 31989046 >> can't identify protocol >> java 21299 ubuntu 91r sock 0,6 0t0 31986504 >> can't identify protocol >> java 21299 ubuntu 92r sock 0,6 0t0 31987223 >> can't identify protocol >> ... >> >> with a new one every couple of minutes. > > I wonder whether it is possible to get some numbers in Access Log to > match with lsof output. So to get a clue what kinds of requests result > in the leak. > > a) normal dynamic requests > b) comet or asynchronous requests > c) requests for static files that are served via sendfile
For my app (which fails on 7.0.23 and uses the APR Connector), there are no comet requests. 99% of the requests are normal dynamic requests, and the remaining 1% are static files. > Maybe there are timeouts, or connections closed at client's side. > > > It should be easy to exclude sendfile: > > a) When sendfile is used it is visible in access log, because a static > file is requested and file size that is logged as 0 (until 7.0.24). > See https://issues.apache.org/bugzilla/show_bug.cgi?id=52316 > > b) If it easy to turn it off, by setting useSendfile="false" on a Connector. > > >> No OOM issues, no errors in log files, until the eventual SocketException >> when ulimit is reached: > > I wonder whether there were some thread deaths. If that happens the > ThreadGroup.uncaughtException() method will print the stacktrace > directly into System.err. That is it will be written to catalina.out > file (and it wouldn't be written to catalina.log). > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org