On Tuesday, October 21, 2003, at 08:05 AM, Shapira, Yoav wrote:
Howdy,
I'm having a problem with a particular application that grows and grows
in size until the jvm runs out of memory, and tomcat shuts down. I am
on a box with 1GB of memory and 350MB+ of swap. I have tried various
settings in my catalina.sh, which just seem to make the app crash even
quicker. I suspect that the problem lies in my code, but I don't know
exactly where to start looking.
One possibility is to use a profiler, such as OptimizeIt or JProbe, which shows you memory differences on the heap between two instances of time. You'll be able to see what has been allocated, and where it's referenced.
Any recommendations here? They are a little pricy, and I would want to make sure I'm getting bang for my $$
As you know, it's not easy to create outright memory leaks in java. The
garbage collector will collect objects that are no longer referenced by
anything, and return their memory to the heap. So you should make sure
you're not keeping references to objects you don't need. One likely
place for this to happen is in class (static) variables.
I will check this out. I do have some...
What JVM settings have you tried, and with what results?
various combinations (and numbers) of the following with the result that the tomcat shuts down rather quickly, or fails to start at all due to lack of memory. (tomcat and apache are the only things running on this box).
## CATALINA_OPTS="-Djava.awt.headless=true -Xmx256m" ## CATALINA_OPTS="$CATALINA_OPTS -XX:NewSize=64m -XX:MaxNewSize=64m" ## -Xms128m -Xmx256m -XX:NewSize=64m -XX:MaxNewSize=64m ## JAVA_OPTS="-server"
constructs cause memory to leak in java? I have some listener classes in my app. Are they a problem? Sessions? Database connections (no pooling)? Any of these things red flags?
Be careful with listener classes to not hold on to unneeded references.
For example, if you have a session listener, and you add each session to
some map or list on the session's creation, make sure to remove it from
your map or list when it's destroyed. You have to listen to both
events. If you don't remove it, you keep a reference to it, it will
stay in memory, and that's a memory leak.
tomcat 4.1.18, classes12.jar (from oracle), and xmlparserv2.jar (also oracle) java version 1.4.0_00 solaris 9 (SunOS 5.9)
Upgrade to JDK 1.4.2 if you can. Upgrade to tomcat 4.1.27 if you can. And you should have a very strong reason to use xmlparserv2.jar from Oracle -- what is it? Why not xerces?
I can, and will!! You guessed it, xmlparserv is a set of xml parsing (sax and dom) tools.
thanks much!
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
