> From: Christopher Schultz [mailto:[EMAIL PROTECTED] > Subject: Re: Recovery from OutOfMemoryError? > > > (Sorry for not responding sooner. Went out to dinner and to see the > > Spider Pig movie :-) > > Nice. ;)
The pig completely disappeared half way through the movie, but there are rumors it will show up at the beginning of next season. Was the pig's vanishing related to the guilt trip Santa's Little Helper admitted to at the end? Inquiring minds want to know... > Which JVM are you working on, though? One of the > mainstream ones? The one we ship for our mainframes is based on Sun's current one, but uses our own allocator, GC, and JIT, among other things. The replaced GC mechanism does not change the visible semantics of such operations, just the internal workings. > Or something designed to be super high-availability (not that the > mainstream ones aren't...)? I don't think it's any more or less reliable than other HotSpot-based JVMs. > The only conclusion that I could draw was that some user (or several > users) caused the OOME and permanently disabled the server. One possibility is that there's really an ongoing memory leak in his webapps, and enough junk accumulates to eat up most of the heap after a while. Then a large, unsatisfiable request is made, there's no recovery logic built into the app, and the failure leaves some application structures in an inconsistent state. > The server should keep going, right? It should indeed. The fact that it doesn't says he may be doing something odd at the time of the failure. > Maybe he's busting his PermGen, but that's unlikely since he says > it only happens under peak load. Due to the use of reflection within Tomcat, there are many anonymous classes created during normal operation. These are discardable immediately after processing of each request, but I suppose if enough requests are going on concurrently and the size of the PermGen was marginal to begin with, it could be the source of the problem. Really need a lot more details to answer this. > So, what is the likely cause of the tech support call? Simply leaving up a lock could hang the application. (Referring to the java.util.concurrent kind here, not synchronized blocks or methods.) Leaving out a simple finally clause to release resources in failure cases can easily result in a dead webapp. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
