Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aganguly@gmail.com designates
 209.85.215.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPvtZefNqvJNXAyWHPa0TTJBNyjMwiVKU=MWdty7+OVFhZowFA@mail.gmail.com>
References: <4F037086.8020901@apache.org>
	<CAPvtZefNqvJNXAyWHPa0TTJBNyjMwiVKU=MWdty7+OVFhZowFA@mail.gmail.com>
Date: Fri, 13 Jan 2012 17:58:41 -0800
Message-ID: 
 <CAJkSUv_k7A_gDFtJeth_C-WwqD5rfY7rb+_063NJ8fPduN-aKg@mail.gmail.com>
Subject: Re: 7.0.22+ fd leak with APR/native
From: Arijit Ganguly <aganguly@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=f46d0408d9231059b204b6735263

--f46d0408d9231059b204b6735263
Content-Type: text/plain; charset=ISO-8859-1

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 <mw@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 <markt@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

--f46d0408d9231059b204b6735263--