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

Randall R Schulz wrote:
> On Sunday 13 April 2008 23:43, Attila Szegedi wrote:
>> ...
>>
>> You're right though that if you have one thread that attempts to
>> allocate a huge chunk of memory and fails, that is atomic, its
>> effects are local to that thread, and it won't affect any other
>> thread. If you know your code will be doing that, then in such a
>> circumstance it can be reasonable to catch OOME and attempt to
>> recover from it (if the context of the problem at hand allows
>> recovery from it). I was under impression that Randall described such
>> a single-threaded scenario and said that even in it he failed to
>> recover from an OOME, which honestly I do find puzzling; as the stack
>> unwinds, stack frames are being discarded along with strong
>> references they hold, so I think that should work...
>
> But in my situation, memory demand comes as a large number of small
> allocations many of which have long lifetimes. When I catch the OOM
> error, sometimes I can carry on after freeing my population of
> instances, requesting a GC and indicating a failure through the
> program's ordinary status reporting mechanism. But in some cases, I get
> another OOM soon after, and that one is fatal, of course.
>
> As far as it being single-threaded, when running as a CLI command, it is
> (JVM threads notwithstanding), and in that setting it's no big deal if
> OOM handling is disorderly.

And this is of course what Bob tried to hint to you: Fork a JVM doing
each computation, "CLI style". The JVMs that return with a result are
good, and the JVMs that don't return a result are also good (they failed!).

And Attila had a good point about concurrent users and shared memory,
which ALSO would have been pretty much fixed, or at least be
consistently handled, by this approach (given that you had some limit
and queue on how many "outstanding JVMs" you were willing to have running).

Endre.

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

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