I am curious to know if this leak is related to unix sockets, or the IPv6 file handles. I have seen a similar issue with the NIO HTTP handler, where it does not close some connections properly and they incarnate as file handles corresponding to unix sockets (all pointing to same inode number). Even 7.0.21 has problems.
Thanks, Arijit On Fri, Jan 13, 2012 at 4:24 PM, Mike Wertheim <m...@hyperreal.org> wrote: > Has a bug been logged for this issue (what seems to be a file descriptor > leak)? > > On Tue, Jan 3, 2012 at 1:17 PM, Mark Thomas <ma...@apache.org> wrote: > > I am trying to bring together all the information I have gleaned on this > > so far from the multiple threads to try and find the common factors. > > > > So far I have: > > - 7.0.21 is OK > > - 7.0.22 has an fd leak > > - 7.0.23 has an fd leak and may leak faster than 7.0.22 > > - occurs with APR/native > > - does not occur with BIO > > - has been observed in HTTP & HTTPS > > - use of Comet does not trigger it > > - use of compression does not trigger it > > - separate connection and keep-alive timeouts does not trigger it > > > > It may be related to POST processing. > > > > I have tried (and so far failed) to reproduce this. I'll be looking at > > POST processing next. In the meantime, here are some further questions > > to try and narrow things down: > > > > 1. Does the application where this is observed make use of Servlet 3.0 > > async requests? > > > > 2. Does this leak occur when the NIO connector is used? > > > > 3. Are there any exceptions in the logs that weren't present in 7.0.21 > > or earlier? > > > > 4. Does the leak occur if sendfile is disabled? > > > > I also have reviewing the 7.0.21 to 7.0.22 changes on my todo list but > > there are quite a few as I was refactoring the connectors to reduce code > > duplication and ironically, reduce maintenance requirements, at the time. > > > > --------------------------------------------------------------------- > > 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 > >
