On 13.05.2009 08:07, Peter Crowther wrote: >> From: André Warnier [...@ice-sa.com] would it not be easier to catch >> the OOM exception and then return a "sorry, server overloaded" page >> to the browser ? > > At that point, it's too late. A thread, somewhere in the system, > tried to allocate some memory for an object and couldn't. This could > happen anywhere! It might be while allocating the buffer to read the > request, or the buffer to send the response, or even the socket > instance from which to read the request. > > There are then no guarantees. You may be unable to send anything > back to the client, as you may be unable to access the socket because > the OOM was caused by trying to create that socket. Or the thread > that got the exception might be one of the threads processing > incoming requests. Once the system encounters an out-of-memory > error, you pretty much have to stop the process and start again, as > you generally have no idea what else has failed. You can't even save > any outstanding work to file, as there's no guarantee you can > allocate the memory for the file object - if MS Word runs out of > memory, you just lost your document! > > This isn't unique to Java, by the way - if you want a coding > nightmare, try to handle *all* malloc() fails in a reasonably sized C > program. Or kalloc() calls in a kernel :-). When you realise that > running out of memory means you can no longer guarantee to allocate > any new memory for any purpose at all, the scale of the problem > becomes apparent.
+1! Another example for "no more guarantees": after an OOME in heap, your business logic might be broken in a very unexpected way! Don't let any Java process do more work once it had an OOME in heap. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
