Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of knst.kolinko@gmail.com
 designates 209.85.212.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50981D76.7040505@christopherschultz.net>
References: <50981D76.7040505@christopherschultz.net>
Date: Tue, 6 Nov 2012 19:37:07 +0400
Message-ID: 
 <CABzHfV=-sivy9J6TpnXs+bJGd5eC-ibk7TTvupjYn=WdtmA7Cg@mail.gmail.com>
Subject: Re: WebappClassLoader weak/soft reachable
From: Konstantin Kolinko <knst.kolinko@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

2012/11/6 Christopher Schultz <chris@christopherschultz.net>:
>
> I was playing around with the manager webapp today and just for grins,
> I redeployed my webapp and then hit the "Find Leaks" button to see how
> long it would take Tomcat to decide that my webapp reloads cleanly.
>
> It didn't. That is, my webapp does not appear to cleanly reload. Which
> was a surprise to me.
>
> I waited a few moments and tried again: Find Leaks still says "there's
> a leak, confirm with a profiler". So I attached with YourKit, took a
> memory snapshot and started looking around: I found 4
> WebappClassLoaders (1 for manager, 1 for my webapp, 1 for a dummy ROOT
> webapp I have and finally a started=false WebappClassLoader for the
> old pre-reload of my webapp).
>
> Interestingly, the started=false WebappClassLoader says that it is
> Weak/Soft Reachable. That means that tracing GC roots doesn't really work.
>
> Requesting GC via the manager changes nothing. Requesting GC via the
> profiler changes nothing.
>
> Does anyone have any good ideas for tracking-down what is keeping this
> WebappClassLoader in memory? Do I just have to intentionally exhaust
> the heap to convince the MM/GC that it should toss-out this WCL?
>
> Any suggestions would be greatly appreciated.
>

1) There exists an -X option that disables explicit GC calls. I hope
that you are not using it.

2) I know of a bug in JVM when a certain kind of leak goes undetected.
I mean the leak through a shared Exception instance and its native
stacktrace. See

https://issues.apache.org/bugzilla/show_bug.cgi?id=50460
https://issues.apache.org/bugzilla/show_bug.cgi?id=53936
(Linked from https://wiki.apache.org/tomcat/MemoryLeakProtection)

Best regards,
Konstantin Kolinko

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