DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4361>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4361 SsiServlet potentially leaks files ------- Additional Comments From [EMAIL PROTECTED] 2001-10-23 13:17 ------- Well, my "lengthy" operation succeeds if SSI operations have been disabled, and fails if SSI is enabled. The problem may of course be in my own application too, but between the successfull and failed tests cases, the only thing that is different is that wether SSI has been enabled or not. The same application has also proven to work in other production environments, so I have some confidence on it. On the other hand, Tomcat4 is a new and different runtime environment, so it may be that some old problem is just now manifesting itself in my application. Anyway, the SSI servlet must surely open a stream to the material it is about to include into a master document, so the big question is, does the servlet ever close that stream explicitly? And does it do it right, like this: InputStream in = someOpenOperation(); try { : } finally // Close the stream even if something goes wrong { in.close(); } Anyway, to make sure, I also run some 'lsof' tests. Without SSI servlets, my Java application kept about 4.000 open files at any given time. However, with SSI servlets enabled, the number started to grow. Although the garbage collertor (or something) seemed to periodically close files, the average number of open files soon exceeded 10.000, and the peak values grew near 80.000. And after some time, the peak value hit 100.000, halting effectively all server services. After the test, the number remained high until Tomcat was restarted, and all was well again. Here is a sample of the number of open files data, taken at 2 second intervals, and at the moment the "Too many files" errors started to appeared. As you see, there is some cyclic behaviour, but the average increased all the time. 36351 43159 49996 57696 62826 67088 77168 88502 96290 110256 100572 44237 48503 56869 63395 71967 80834 87933 100460 115717 118438 118438 118424 118438 118429 118438 As a final minor detail, I should propably mention that I'm mapping the SSI servlet to *.html file name pattern. This is propably not significant, but you never know ...
