tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Migration from Tomcat 7 to 9 results in more open file descriptors
Date Thu, 23 May 2019 15:14:45 GMT
Hash: SHA256


On 5/23/19 06:59, Florian Trimmel wrote:
> After migrating from Tomact 7 to Tomcat 9.0.20 (running with same
> Java Version 1.8.0_25) we have a problem with our JSF2 web
> application on Linux RHEL 7. After some time we get Exceptions like
> this:
> /f4m/tomcat/tomcat_f4mbs/webapps/ACM/WEB-INF/acm-config.xml (Too
> many open files)
> at Method)
> at
> at<init>(
> at<init>(
> After searching around a while, I have found out that there are
> many open file descriptors to xhtml files

Do you know if your application opens these files, or are they
(likely) being opened by Tomcat in response to incoming client
requests for those files?

> [snip]
> This is not the complete list - there are many more.
> The number of listed files goes up and down. For me it seems that
> xhtml (or one of its used components) has an open file descriptor
> as long as a page is shown in Browser.

... and when you close the browser, the fd is closed too? Spooky.

> I already know how to increase the maximum number of open file
> descriptors, what bothers me is that if I deploy the same
> application on Tomcat 7 again, I can only see open file descriptors
> for JAR Files, Sockets, but NEVER for xhtml's.
> Can someone please explain why this happens?

The obvious explanation would be a fd leak within Tomcat but I see no
data to support that. The "resources" (aka file-reading)
implementation changed between Tomcat 7 and 9 and if your application
is being a little lazy about resource-management, this could cause fds
to be left open now where they were being cleaned-up for you in the past

Improper caching configuration could also leave file descriptors open,
but multiple fds open to the same file is the exact opposite of
caching, so the configuration would have to indeed be particularly bad.

Are you able to attach a profiler to the JVM process? If so, try
launching Tomcat, attaching the profiler, and then making some
requests. The profiler ought to be able to show you where certain
objects were allocated and you can track-down where e.g.
FileInputStream objects are created. If they are being created in
Tomcat's code without being called from your application (e.g. from
within DefaultServlet), then something is very wrong.

But at this point, the new resources implementation is fairly mature
and I wouldn't expect it to leak like this.

- -chris
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message