Are you using the context reloading feature? "reloadable=true" or using the tomcat manager app will cause this to happen eventually.
Really? Prove that please...
Actually, I can't prove it in his instance, but I have proved it time and time again on ours. I'm using 4.0.4 right now though so I haven't verified 4.1.x. But, I heard that this is still the case in 4.1.x.
To reproduce this problem just reload a context over and over. Depending on how much memory it uses, it will start throwing OutOfMemory exceptions long before the -mx JVM parameter value is ever reached. eg. I do a ps on linux and it shows it as using like 140M or something like that and it already starts throwing out of memory exceptions.
Aah. I think I see a part of the problem. First of all, the amount of memory shown by 'ps' is completely irrelevant, except that it shows how much memory that the OS has allocated to the Java process. This is allowed to be more than the "max heap size" set for Java.
The heap is not related to the amount of memory the OS allocates, except that the OS report will always be larger than the heap report from Java.
You can get an OOM even if you have the heap set to 1GB and yet the process only has 50MB used. This is because OOMs usually happen *while the GC is doing its work*. I'm not sure if there's another thread that increases the actual size of the heap for you, but if so, I'm sure it's related to the GC anyway.
So, moving on, what usually happens is that a "low memory" condition triggers a GC (usually a "full" GC). When the GC runs, it needs some memory to work with. If it cannot allocate memory for itself, it will die with an OOM. If the heap hasn't increased, yet, then the GC cannot allocate more objects on the heap to do it's thing. That can explain why you get an OOM when you are way under the heap "size" in the output of ps.
With our applications that we're running, we can usually get away with roughly 5-10 context reloads.
Do you have any 3rd party containers or such that live outside of the context (their JARs would be in CATALINA_HOME/server/lib or CATALINA_HOME/common/lib -- someone please confirm that the second of these two does *not* get discarded along with the rest of the context upon reload). If you are using 3rd party containers like this, they will not dump their contents when you re-load the servlet context. If you have static "singleton" instances of these, then you'll likely fill up memory all the time.
This could also be related to the "Java doesn't GC java.lang.Class objects" thread that's going around this week, too.
-chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
