Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4DC05AF1.6030407@christopherschultz.net>
Date: Tue, 03 May 2011 15:43:45 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: 100% CPU Usage when stopping Tomcat after OOM condition
References: <4DC00FA3.8010705@christopherschultz.net>
 <4DC01304.5020302@apache.org> <4DC0154F.7010908@ice-sa.com>
 <4DC016B3.60601@apache.org>
In-Reply-To: <4DC016B3.60601@apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark,

On 5/3/2011 10:52 AM, Mark Thomas wrote:
> On 03/05/2011 15:46, André Warnier wrote:
>> Mark Thomas wrote:
>>> On 03/05/2011 15:22, Christopher Schultz wrote:
>>>> All,
>>>>
>>>> Moments ago in our development environment, our webapp suffered an OOME
>>>> after many re-reployments (we know we have an undeploy-related leak).
>>>> When attempting to bounce Tomcat, the shutdown failed and I took a
>>>> thread dump which included the one non-trivial thread shown below.
>>>>
>>>> I haven't looked at the code yet to see if there is some kind of loop
>>>> around this code, but top reported 100% CPU usage from this process so I
>>>> suspect something like that was happening.
>>>>
>>>> We are using TC 6.0.32 on Debian Lenny and Sun/Oracle 32-bit
>>>> 1.6.0_22-b04 Server VM.
>>>>
>>>> This is less of a "help" request as it is an observation of an
>>>> unfortunate situation: the OOME is clearly the real problem and has
>>>> nothing to do with Tomcat itself. Unfortunately, after the OOME, Tomcat
>>>> was unable to shut down gracefully and that could be a problem in and of
>>>> itself.
>>>
>>> After an OOME there are no guarantees as to the state of the JVM. That
>>> Tomcat is unable to shut down cleanly in that case is not suprising.

Chuck's assertion is that an OOME isn't fatal to the JVM but almost
always fatal to the application since it's unlikely equipped to handle
the bizarre situations that arise from it's occurrence. A bit of a
hair-split if you ask me, but it's always worth examining any options TC
has to at least be able to stop itself gracefully.

>> Do I not remember seeing somewhere, at some point, a parameter named
>> "OOMParachute" or similar ?
> 
> Yes, in the NIO connector. It may, or may not, provide the JVM with
> enough memory to exit gracefully.

Since this is a PegmGen issue, it's unlikely that the NIO connector's
OOM parachute will help, here. Also, I'm not using the NIO connector :)

Any reason the parachute is in the /connector/ and not somewhere more
universal?

I was mostly interested in why I was getting 100% CPU usage... checking
the code, I *do* see a loop in
WebappClassLoader.clearReferencesStaticFinal but it's over an iterator
that will presumably run out of entries. The CPU spike seems to be
happening within the native code in java.lang.Class.getDeclaredFields,
so there's nothing TC can do to prevent it. :(

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3AWvEACgkQ9CaO5/Lv0PAodwCfUxrRVV0TZihjiS1d6QwF1LCo
8PgAn3jOrCy4IvUTe4diJ68gGrqIyQXZ
=Ys5e
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org