tomcat-users mailing list archives

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

Florian,

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:
> 
> 
> 
> java.io.FileNotFoundException: 
> /f4m/tomcat/tomcat_f4mbs/webapps/ACM/WEB-INF/acm-config.xml (Too
> many open files)
> 
> at java.io.FileInputStream.open0(Native Method)
> 
> at java.io.FileInputStream.open(FileInputStream.java:195)
> 
> at java.io.FileInputStream.<init>(FileInputStream.java:138)
> 
> at java.io.FileInputStream.<init>(FileInputStream.java:93)
> 
> 
> 
> 
> 
> 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
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzmuOUACgkQHPApP6U8
pFgqwg/9FUmsAS/mOin0NKIlU1LOPRyf72/gT+8n5vyquC+CBk8jWFBqxNFZEoGV
Fc+5rfwF1pqK8aTgDM2dzEb4bJ9s3sVGY/SLvspGyeRU81/uqZW4CnSGIL7VzrJk
xpTi4hk02rNFbq8yNjMDqCUx2t41Bi8NUVJh9TUtHRPZRQWhy3JsG32HQdPrPklj
AipBl/NkpizGZQlAGqMz87rYvFIEz1e1hA47CPfUFg7x8WCib7X9JcHHZYF5gQjS
y/h5IdRT9A6F1Lu2arW00cFPSfoYoZA+gHWzQMGHmTXSQplwzF8h9tafNLXf4u4u
Knav+K3KTPeskzuKUqxLTa2GwX6MNLnEnw3uicvuHT13JYncLTz6LCgSE31/xgj9
EcnME4zQca7X14DrHaldwwejuvqL/HYTVkYc6YOt24E3FCAbkcPg8MOYo1QjT408
u1GXl+n4HBgNsHO//FsAVYDEm14YXmvWyB+33aVc9OKbCk1X+vRbkq8Fe//Bz05T
72Mb5potJWGFhHVseSuiYp1XyhlgSWDqzQkqoYV8ffm5ecfbYd96gRqFxveK0S2I
9/9X6k8a/6lqQMidfNoqKfoA1G+5soI436j6LYlna4vqIgB+ZjCoTmnzJh4+NMy7
VcAZ+S2uRb3bnTccsttcNbCKOM9BD9C9rSosS3N48XDl3u5ooL4=
=B0WJ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message