tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <Chuck.Caldar...@unisys.com>
Subject RE: Recovery from OutOfMemoryError?
Date Wed, 01 Aug 2007 14:20:38 GMT
> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
> Subject: Re: Recovery from OutOfMemoryError?
> 
> > (Sorry for not responding sooner.  Went out to dinner and to see the
> > Spider Pig movie :-)
> 
> Nice. ;)

The pig completely disappeared half way through the movie, but there are
rumors it will show up at the beginning of next season.  Was the pig's
vanishing related to the guilt trip Santa's Little Helper admitted to at
the end?  Inquiring minds want to know...

> Which JVM are you working on, though? One of the 
> mainstream ones?

The one we ship for our mainframes is based on Sun's current one, but
uses our own allocator, GC, and JIT, among other things.  The replaced
GC mechanism does not change the visible semantics of such operations,
just the internal workings.

> Or something designed to be super high-availability (not that the
> mainstream ones aren't...)?

I don't think it's any more or less reliable than other HotSpot-based
JVMs.

> The only conclusion that I could draw was that some user (or several
> users) caused the OOME and permanently disabled the server. 

One possibility is that there's really an ongoing memory leak in his
webapps, and enough junk accumulates to eat up most of the heap after a
while.  Then a large, unsatisfiable request is made, there's no recovery
logic built into the app, and the failure leaves some application
structures in an inconsistent state.

> The server should keep going, right?

It should indeed.  The fact that it doesn't says he may be doing
something odd at the time of the failure.

> Maybe he's busting his PermGen, but that's unlikely since he says 
> it only happens under peak load.

Due to the use of reflection within Tomcat, there are many anonymous
classes created during normal operation.  These are discardable
immediately after processing of each request, but I suppose if enough
requests are going on concurrently and the size of the PermGen was
marginal to begin with, it could be the source of the problem.  Really
need a lot more details to answer this.

> So, what is the likely cause of the tech support call?

Simply leaving up a lock could hang the application.  (Referring to the
java.util.concurrent kind here, not synchronized blocks or methods.)
Leaving out a simple finally clause to release resources in failure
cases can easily result in a dead webapp.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message