I have recently changed a lot of my old perceptions on this matter after
reading this excellent article:
http://www.ibm.com/developerworks/java/library/j-jtp01274.html
If you change your mindset when you write your apps to consider how the
garbage collector actually operates, then those memory errors are less
likely to come back and bite you. And on the subject of soft references,
I started using them as well as transient decelerations on some objects
I didn't need to persist in serializable classes and it really helps
reduce the load. Java 6 also comes with JConsole, a really handy
profiling tool, make the most of it.
Peter
Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: Recovery from OutOfMemoryError?
(Sorry for not responding sooner. Went out to dinner and to see the
Spider Pig movie :-)
Actually, my past experience has been that it's the GC
thread that OOMEs, not a worker thread.
Assuming we're talking about a current HotSpot-based JVM, the threads
doing GCs cannot get OOMEs, since they are dedicated to doing just GC
operations, and never do any object allocations themselves. On older
JVMs (and some from other vendors), the thread that initially encounters
an allocation failure also does the GC; if the GC fails to recover
enough memory, it can generate an OOME for itself.
It has always been my understanding that a JVM that suffers an OOME
is all but done for.
The JVM itself doesn't care about any exceptions thrown at the
application. There are certainly a ton of applications that handle such
error conditions very badly, and hang themselves up by doing such things
as trying to display messages rather than nulling out now useless
references. Some of the stress-testing of our JVM involves running apps
designed to provoke OOMEs; these readily recover and keep on truckin'.
The OP would seem to corroborate this claim, since it sounds like his
whole app server becomes unresponsive once he gets an OOME (hence the
early morning phone calls).
The supposed timing of the phone calls leaves me somewhat skeptical;
what are they running where the peak load occurs at 3 AM?
If your assertion (OOMEs can be ignored, since only one allocation
fails and the rest of the VM is fine) were true, then the OP would
not be getting any calls in the middle of the night: the user would
simply re-try the request and (hopefully) get a result the second
time.
That's not what I said at all. Each logical module should be designed
to handle such situations, typically by discarding what has been done up
to the point of failure, and then returning an error to its caller.
What is likely to have happened instead in the OP's case is that the app
encountering the OOME had no provision at all for error recovery, and
simply quit, leaving many now useless objects around with live
references to them. It may have even made matters worse by trying to
generate an error message of some sort.
- 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652
If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
