-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
