Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of p.stavrinides@albourne.com
 designates 213.207.142.98 as permitted sender)
Message-ID: <46B01B22.8060209@albourne.com>
Date: Wed, 01 Aug 2007 08:33:22 +0300
From: Peter Stavrinides <p.stavrinides@albourne.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Recovery from OutOfMemoryError?
References: <C72697B949D6CE4A8C6D4971BC26F900DEBD69@exchange1.portblue.com>
 <46AF8A4A.90501@christopherschultz.net>
 <AEF3D568DD1D9E428048C592AA164597061E84B5@USRV-EXCH4.na.uis.unisys.com>
 <46AFB6C8.6010907@christopherschultz.net>
 <AEF3D568DD1D9E428048C592AA164597061E8610@USRV-EXCH4.na.uis.unisys.com>
In-Reply-To: 
 <AEF3D568DD1D9E428048C592AA164597061E8610@USRV-EXCH4.na.uis.unisys.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit

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:chris@christopherschultz.net] 
>> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>   

-- 
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org