Tomcat OutOfMemory Exception

[premesh purayil]

My app seems to have memory leak i would assume. Its basically an abstraction ontop of a database but when i run unit tests on a client application which calls out to this service it eventually yacks. If i run the unit test classes individually its fine (although after a number of them i run into the same problem) but if i run the whole suite (350 tests) its bombs out on the same test every time... ( that test basically causes one write and a read from the underlying DB). Whats the best way to tack where my problem specifically? takes 45 mins of unit tests to replicate this and setting breakpoints searching for the problem has been VERY difficult... suggestions?
here is the stack trace..
0060111|094336062|14|SEVERE|caught throwable
20060111|094337504|15|SEVERE|Exception invoking periodic operation:
20060111|094345516|13|SEVERE|caught throwable
20060111|094349862|11|SEVERE|caught throwable
ERROR: 'null'
FATAL ERROR: 'Could not compile stylesheet'
20060111|094351885|14|SEVERE|WSS0147.unableto.use.stylesheet
20060111|094351885|14|SEVERE|unableto.dump.soapmessage
20060111|094353197|14|SEVERE|JAXRPCTIE01: caught exception while handling reques
t: javax.xml.rpc.soap.SOAPFaultException: Unable to dump SOAPMessage
20060111|094355140|13|SEVERE|caught throwable
20060111|094401369|11|SEVERE|caught throwable
20060111|094404424|13|SEVERE|caught throwable
20060111|094405776|14|SEVERE|caught throwable
20060111|094407859|13|SEVERE|caught throwable
20060111|094410212|14|SEVERE|caught throwable
20060111|094412355|13|SEVERE|caught throwable
20060111|094414158|11|SEVERE|caught throwable
20060111|094417233|13|SEVERE|caught throwable
20060111|094417233|11|SEVERE|Caught exception (java.lang.OutOfMemoryError) execu
ting org.apache.tomcat.util.net.TcpWorkerThread@7d27b0, terminating thread
20060111|094432595|15|SEVERE|Exception invoking periodic operation:
java.lang.OutOfMemoryError
20060111|094440557|14|SEVERE|caught throwable
20060111|094442610|13|SEVERE|caught throwable
20060111|094444353|14|SEVERE|caught throwable
20060111|094445925|13|SEVERE|caught throwable
20060111|094537481|15|SEVERE|Exception invoking periodic operation:
20060111|094648857|15|SEVERE|Exception invoking periodic operation:
20060111|094800302|15|SEVERE|Exception invoking periodic operation:
20060111|094911648|15|SEVERE|Exception invoking periodic operation:
20060111|094952859|15|SEVERE|Exception invoking periodic operation:
java.lang.OutOfMemoryError
java.lang.OutOfMemoryError

[William Brogden]

I think that if this was my problem I would first try to use the Tomcat Management Application to monitor Tomcat memory use and Thread count. Tomcat 5 has quite a nice browser interface for this.
For example, I discovered an app that was putting each request Thread in an infinite loop and thus consuming memory.
Bill

[Balaji Loganathan]

I am moving this to our Tomcat forum. Please continue ur discussion there.

[premesh purayil]

hmmm when i use the Tomcan manager for the server status i see this while running my unit tests against the service. Shouldnt i not have this many active sessions if my unit tests are ment be consecutive tests...

Startup time: 10 ms TLD scan time: 0 ms
Active sessions: 202 Session count: 202 Max active sessions: 202 Rejected session creations: 0 Expired sessions: 0 Processing time: 0 ms
JSPs loaded: 0 JSPs reloaded: 0
default [ / ]

[William Brogden]

That does look like a lot of active sessions alright! Since the default sesssion timeout is typically 30 min, they can hang around for quite a while. Calling session invalidate() when you are sure the session will no longer be needed may help.
What sort of references are being stored in the session?
Bill

[Ben Souther]

If your test suite is not passing the session id back with each request, Tomcat is going to create a new session for each hit.

What are you using for testing?

[Ben Souther]

I may just be that your app requires more memory than the default 64k that the JVM allots itself. If you're doing SOAP Parsing and saving lots of objects in session.

Try increasing your heap size.
If it is a memory leak than increasing it will only postpone the inevitable but you may see the memory usage level off at some point.

Another experiment would be to stop and let some sessions expire then resume.
If you know it dies after 350 hits, then run 330 and stop for 35 minutes to let all the sessions expire. Then try running another 330. If the problem was due to a leak, then it should die after 20 hits into the second round.

[premesh purayil]

The app is fairly thin. We implemented an API that basically wraps the web service which then makes db calls ( obviously there its a little more complex than that underneath) . There isnt an in memory state or any persisting being done in the web service. Im goning to try the suggestion of running the tests (using Junit in JBuilder) right until a couple before where i know it fails and then wait for 30 mins or so to see if the session count goes down so i can try to continue. It is odd that it seems like a sessions is created for every call against the API. It should be acting like one user with one session making calls agains the API ... The sessions have some information in it but its minimal.. whats the max number of sessions Tomcat can maintain on the default heap size?
will post more after the tests

[Ben Souther]

A session is nothing more than a map of references to objects living on the heap so there is no hard limit on it's size.

In order for your testing tool to act like one user, it would need to send the session id header with each request.
I have a little "poor man's load tester" that I wrote.
In it, I set the JSESSIONID cookie so that the server will treat it as the same user.

URLConnection con = url.openConnection();
con.setRequestProperty("Cookie", "JSESSIONID=" + sessionId);
[ January 15, 2006: Message edited by: Ben Souther ]

[Naveen KumarPm]

I am getting below error

org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor
processChildren

SEVERE: Exception invoking periodic operation:

java.lang.OutOfMemoryError: GC overhead limit exceeded

at
java.lang.StringCoding$StringEncoder.encode(StringCoding.java:232)

at java.lang.StringCoding.encode(StringCoding.java:272)

at java.lang.String.getBytes(String.java:947)

at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)

at
java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)

at java.io.File.isDirectory(File.java:754)

at
org.apache.naming.resources.FileDirContext.list(FileDirContext.java:901)

at
org.apache.naming.resources.FileDirContext.listBindings(FileDirContext.j
ava:332)

at
org.apache.naming.resources.ProxyDirContext.listBindings(ProxyDirContext
.java:516)

at
org.apache.catalina.loader.WebappClassLoader.modified(WebappClassLoader.
java:741)

at
org.apache.catalina.loader.WebappLoader.modified(WebappLoader.java:478)

at
org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.j
ava:399)

at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.j
ava:1309)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.proc
essChildren(ContainerBase.java:1601)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.proc
essChildren(ContainerBase.java:1610)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.proc
essChildren(ContainerBase.java:1610)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(
ContainerBase.java:1590)

at java.lang.Thread.run(Thread.java:619)


Please suggest me why this is coming.