Hello,
I tried to send this message before but it got bounced -- probably the attachments.
I've deployed a Java servlet that gets about 300-400 hits a day.
Tomcat (standalone mode) keeps running out of memory and crashing.
The servlet does an XSLTC transformation on an XML file about 1.5MB large,
sending html to 'out'.
Tomcat is dedicated to just this "little" servlet and some JSP data entry tools used
to maintain the XML file. I've found that even when we refrain from using the data
entry tools, and just let the servlet run, the problem still happens.
At first, I thought I must be doing something wrong. So I did every thing I could
to plug memory leaks in my code to free up resources once they are no
longer referenced. I've closed all streams and set the transformation objects
(dom, parser, translet) to null immediately after the transformation is done.
I've collected data and can send you a graph. Today it showed the heapsize
-- (rt.totalMemory()-rt.freeMemory() -- stayed around 5-6MB for 178
hits on the servlet. Then it quickly went up. From 190 to 280 hits
it averaged 40MB. Then at about 300 hits it went over 120MB and
the servlet starting giving Out-of-Memory errors soon thereafter.
In the very beginning, I sent mail to the users group and have implemented
suggestions, like increasing the file descriptors to 1024, minimizing sessions
(session.setMaxInactiveInterval(120), starting the Tomcat JVM with more
memory (-Xmx160m). That has helped somewhat. It takes longer to
crash, but it hasn't stayed up more than 24 hours.
Here's the configuration:
- Solaris 2.7 on an Ultra-2 with all the patches.
- one processor with 512MB memory
- Java 1.3 is installed (must have VMPI cause hprof works)
- Tomcat 3.2.2 jars
- Session timeout 120 seconds
- Using the thread pool with
max_threads 25
max_spare_threads 10
min_spare_threads 5
I've been trying for almost a month to get past this memory problem.
Something is wrong. If it is just operator error, then what could be
my mistake. It is looking like a bug in Tomcat or the Java SDK. If
it were a simple memory leak in my application code, then I'd think
the heap size would go up progressively, since the servlet is doing
the same thing over and over. The only difference betwee one hit
from another is the parameters passed from the user that are feed
to the XSLTC translet.
I'm in software QA in the XTC center at Sun. In fact, I've been doing
XSLT conformance testing on Sun's (now Apache XalanJ2's XSLTC) processor.
I don't think the problem is in XSLTC but I'd be happy to be proved wrong.
I'm not on tomcat-dev, so please copy
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Thanks,
Tom
