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

On Monday 14 April 2008 09:04, Bob Lee wrote:
> On Mon, Apr 14, 2008 at 6:44 AM, Randall R Schulz <[email protected]>
wrote:
> > I did essentially this:
> >
> >    <http://www.javaspecialists.eu/archive/Issue092.html>
>
> I wouldn't recommend it. Heinz says himself, "since constructing new
> objects is a rather fast operation in Java, it may happen that the
> JVM runs out of memory before getting a chance to notify us." This is
> especially true when you have concurrent threads.

There's considerable computation associated with each allocation and the
allocations themselves are in rather small increments. The jobs (the
big ones that cause problems) run many seconds (even a minute or more)
and use hundreds of megabytes, so it seems possible to maintain a
reasonable margin.


> If you're interested in exploring multiple VMs more (if only for
> future reference), check out java.lang.ProcessBuilder and keep in
> mind that you can send a serialized result back over stdout.

This is problematic, as well. The server code is a Grails application
(while the prover core is pure Java) and the response it produces is
frequently very voluminous.

While the MemoryMXBean approach may not be ideal, it has already
improved the reliability of my application considerably. Until I have
evidence that it's inadequate, I'm not going to develop a more
elaborate solution. As I said, the Web interface is secondary to
development of the core capabilities (for the next year or so, at
least, and if we don't handle those core aspects, there won't be any
more development...).


> 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