[Swift-devel] behaviour on out-of-memory

[Mihael Hategan]

On Fri, 2008-02-08 at 17:36 +0000, Ben Clifford wrote:
> 
> On Fri, 8 Feb 2008, Mihael Hategan wrote:
> 
> > Not correct semantics when swift acts as a service (think I2U2). I
> > should probably find a way to immediately cancel a whole workflow when
> > OOMs are caught so that client software can un-reference it and
> > eventually get back to stability. But again, not having enough memory
> > may cause arbitrary breakage in arbitrary threads, so it's hard to
> > guarantee consistency after such a thing.
> 
> My philosophy, which is sort of backed up by the javadocs, is that OOM 
> Errors are a signal that the JVM is so broken that it cannot continue - 
> its the end of the universe as far as the JVM is concerned and there's 
> nothing you can do. If you're so foolish as to run something (eg Swift) in 
> your web server JVM that puts the JVM into that state, then sucker to you!

Yes and no. I there are cases when one can safely deal with it and other
cases when it's ok to let it provide partial functionality. I don't want
to definitely do/say one thing or the other at this point.

I've had the same argument with Jarek (or rather the reverse argument).
The WSRF container catches OOMs and does some cleanup and continues. I
said it shouldn't be done. When you have an OOM it's safer to have no
service than to risk nondeterministic behavior or even potential
security problems. So yes, I also happen to agree with you besides
disagreeing with you.

> 
> cf. javadoc VirtualMachineError:
> 
> > Thrown to indicate that the Java Virtual Machine is broken or has run 
> > out of resources necessary for it to continue operating.
> 
> There's a bunch more memory management stuff in java 5 (eg the MXBeans) 
> which are perhaps interesting - eg. when memory gets low, stop doing 
> certain things / more cleanly abort select pieces of what lives in the 
> JVM.
> 

Hmm. Interesting. I have to look at that. It may be time to slowly move
towards java 5.