tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Recovery from OutOfMemoryError?
Date Tue, 31 Jul 2007 22:25:12 GMT
Hash: SHA1


Caldarale, Charles R wrote:
>> From: Christopher Schultz [] 
>> Subject: Re: Recovery from OutOfMemoryError?
>> A thread that suffers an OOME is pretty much hosed, anyway, so
>> counting on it to do any kind of recovery is difficult.
> Why do you say that?  The only thing that failed is the allocation of
> some particular object, leaving the rest of the thread's state intact.

In my experience, OOMEs are not just caused by the failure of a large
allocation, such as a huge array or something, but rather tons of small
allocations. One extra value object that puts the heap over the top.

> In most cases, it's easy to return a failure notification to the
> caller of whatever method encountered the error.

In these cases, attempting to open a file, start a process, send an
email, or even generating an "error" page, etc. would simply result in
another OOME. Actually, my past experience has been that it's the GC
thread that OOMEs, not a worker thread. In this case, the VM really is

You have taken issue with this assertion in the past. It has always been
my understanding that a JVM that suffers an OOME is all but done for.
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). 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.

- -chris
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message