From users-return-233440-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org Sun Apr 8 20:14:52 2012 Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5ED099021 for ; Sun, 8 Apr 2012 20:14:52 +0000 (UTC) Received: (qmail 10448 invoked by uid 500); 8 Apr 2012 20:14:49 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 10205 invoked by uid 500); 8 Apr 2012 20:14:48 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 10195 invoked by uid 99); 8 Apr 2012 20:14:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Apr 2012 20:14:48 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [80.237.132.197] (HELO wp190.webpack.hosteurope.de) (80.237.132.197) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Apr 2012 20:14:43 +0000 Received: from p3e9eece9.dip.t-dialin.net ([62.158.236.233] helo=[10.1.1.251]); authenticated by wp190.webpack.hosteurope.de running ExIM with esmtpa id 1SGyVB-0004gP-H7; Sun, 08 Apr 2012 22:14:21 +0200 Message-ID: <4F81F19C.3020504@mayr-stefan.de> Date: Sun, 08 Apr 2012 22:14:20 +0200 From: Stefan Mayr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: users@tomcat.apache.org Subject: Re: Bug in Tomcat AJP Connector? References: <217DDBC2BB1E394CA9E7446337CBDEF20102DEDB4F4A@il-ex01.ad.checkpoint.com> <4F7C81BB.1040804@apache.org> <217DDBC2BB1E394CA9E7446337CBDEF20102DEDB4FA0@il-ex01.ad.checkpoint.com> <4F7E2E89.5040805@pidster.com> <217DDBC2BB1E394CA9E7446337CBDEF20102DEDB51E4@il-ex01.ad.checkpoint.com> In-Reply-To: <217DDBC2BB1E394CA9E7446337CBDEF20102DEDB51E4@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de;stefan@mayr-stefan.de;1333916083;47b3cfc1; X-Virus-Checked: Checked by ClamAV on apache.org Am 08.04.2012 18:41, schrieb Ofer Israeli: > 2012/4/6 Pid: >> On 05/04/2012 22:17, Ofer Israeli wrote: >>> Y >>> >>> On 5 באפר 2012, at 18:58, "Konstantin Kolinko" >> wrote: >>> >>>> 2012/4/5 Ofer Israeli: >>>>> Mark Thomas wrote: >>>>>> On 04/04/2012 17:02, Ofer Israeli wrote: >>>>>> >>>>>> Once you have an OOME all bets are off. The JVM needs to be >> restarted. >>>>>> There is no guarantee of reliable operation after an OOME. >>>>>> >>>>>> Mark >>>>> >>>>> Hi Mark, >>>>> I agree that there in such a situation the JVM should be restarted, but it >> isn't restarted by Tomcat. On the other hand, Tomcat does take some >> precautious actions and kills the accepting thread, but in such a case it should >> also close the socket that thread is listening on otherwise it is leaving garbage >> around after the thread's death. >>>>> Do you see any reason as not to close the listening socket? >>>>> >>>> >>>> 1. Tomcat does not start JVM thus it cannot restart it. >>>> >>>> You need some external tool or script or admin to perform monitoring >>>> and (re)starts. >>>> >>>> 2. OOM can happen at a random place. Once it happens, it is likely >>>> that other places will also start to fail randomly. It is also likely >>>> that your attempts to recover will fail as well. >>>> >>>> Mark already mentioned it: "all bets are off". >>>> >>>> Best regards, >>>> Konstantin Kolinko >>>> >>> Hi Konstantin, >>> >>> I agree regarding the OOM bringing TC to a state where it must be >> restored, but my point remains: if there is code that handles catching this >> exception and terminating the thread, why not terminate gracefully by >> closing the listening socket before killing the thread? >> >> And your point has been answered. After an OOM the JVM is in an >> unknown, unsafe state so a restart MUST occur to restore service. >> >> Closing a socket gracefully after an OOM is a bit like trying to shut one of the >> portholes on the Titanic, shortly after hearing a large crashing sound. >> >> >> There's only one place I know of where Tomcat attempts to interact with >> OOM conditions and this is not one of them, so I don't believe it's safe to say >> that Tomcat is deliberately handling this exception. >> >> NB an OOM is an Error, not an Exception - it is a subclass of >> VirtualMachineError, which is thrown to indicate that the Java Virtual >> Machine is broken or has run out of resources necessary for it to continue >> operating. >> >> An Error is a subclass of Throwable that indicates serious problems that a >> reasonable application should not try to catch. >> >> >> If anything, the locations where Tomcat catches a Throwable should be >> modified so it does *not* catch Errors, rather than continuing to do so and >> then attempting a trivial tidy-up. >> >> >> p > > Thanks for your input - you're right regarding the error and the fact that Tomcat is indeed catching a Throwable and not an Exception. I assume that if the Throwable were not caught, then the thread would die in any case. Although stated before that Tomcat could not kill itself in such a situation, I still wonder if it would be possible to do so. Or taking a different perspective on this: if the JVM specification is such that it cannot be trusted to continue running after an OOM, then why does it not kill itself or restart itself? > I guess you can do this with some vendor specific JVM arguments as SUNs/Oracles -XX:OnOutOfMemoryError: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html Different findings like "kill -9 %p" let me suspect that you can use %p as a variable for your current pid. With that you can either kill your current instance and let your monitoring handle the rest or try to initiate the restart by yourself. Give it a try Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org