tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files
Date Tue, 23 Oct 2001 20:17:31 GMT
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 rami.hanninen@davisor.com  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 ...

Mime
View raw message