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
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
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 [ / ]
Author and all-around good cowpoke
Joined: Mar 22, 2000
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
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.
Joined: Nov 23, 2004
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
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 ]