Re: Out-of-Memory Handling in Long-Running / Server Applications

On Sunday 13 April 2008 16:56, Bob Lee wrote:
> On Sun, Apr 13, 2008 at 3:59 PM, RRS <[email protected]> wrote:
> > What did you mean by "let them die?"
> >
> > And I don't know what you mean by "incremental results." There are
> > no such things. ...
>
> I guess I don't understand the problem enough to understand why you'd
> have any more trouble catching an OOME in a separate JVM and reacting
> to it than you would in the same VM.

But that's the point. The out-of-memory condition has to be handled,
responded to. I cannot be allowed to terminate the computation.

Catching the OutOfMemoryError is a non-solution. It can't be made to
work reliably.


> The advantage to keeping it in a
> separate VM is that you firewall the troublesome piece of code.

The code isn't troublesome. This is not a erroneous condition. It is
merely exceptional.


> Right now, if your calculation takes up all the memory, you might get
> an OOME in a different thread which tries to perform the smallest
> allocation. This error will likely come in code which isn't written
> in such a way that it can defend against it. Or, as you already
> pointed out, you may get an OOME while trying to recover from the
> original OOME. If you were able to run your calc in its own VM, you'd
> be able to recover w/o the recovery itself tanking the entire app.

As I've implemented it (getting an advanced notification of pending
memory exhaustion), there's little problem with collateral damage. It
does require that I define a percentage threshold of memory utilization
at which I get the notification, but in practice it seems this is far,
far less likely to lead to actual out-of-memory than is the case when
trying to catch the OOM error.


> Bob


Randall Schulz

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com