We are also on REsin 3.1.6.  We restart the server each deploy because of
behavior exactly described below.

Possibly unrelated but also strange issue we see is abnormally long re-start
times, on a 2 server cluster where the process is:

kill server 1
deploy war 1
restart server 1... wait long time for it to restart
then repeat for server 2



On Thu, Oct 30, 2008 at 8:39 AM, Mattias Jiderhamn <
[EMAIL PROTECTED]> wrote:

> Although embarrassed to admit it, we have had long standing problems
> with PermGen memory leaks. We have gotten used to restarting the server
> every time we redeploy, to avoid OutOfMemoryError. Since we would like
> to make use of - or at least evaluate - some of the new Resin features
> like WAR versioning, I thought I'd give fixing this another shot.
>
> I have already been through (and fixed a few of) the usual suspects;
> JDBC drivers, log factories, ThreadLocals, explicit ClassLoader
> references etc. There has also been at least one bug within Resin
> causing leaks (bug 951 in Mantis).
>
> A while back I tried tracking this down using jhat, but since I have
> limited experience with this, time did not allow me to get to the bottom
> of it. Today I found some more time, and also a tip on how to use
> YourKit to track this down
> (
> http://ampedandwired.com/2008/05/05/finding-permgen-memory-leaks-with-yourkit/
> for those interested). This lead me to something interesting, which I
> don't quite understand.
>
> If I interpret the YourKit memory snapshot correctly, here is what is
> happening (from a Resin 3.1.6 perspective):
>
> In com.caucho.server.dispatch.ServletInvocation there is a static
> ThreadLocal holding references to the current (original) request (while
> dispatching?). This means that as long as the executing (and
> dispatching) thread remains in Resins thread pool, but is not used for
> another dispatch, a handle to the original
> com.caucho.server.http.HttpRequest is held. In the request, there is a
> handle to a com.caucho.server.dispatch.Invocation, which in turn has a
> handle to - the application classloader! (And there is your PermGen leak)
>
> Isn't the fact that the ThreadLocal is never cleared an obvious memory
> leak? Or why haven't this been fixed even though Scott seems to have
> noticed this (see
> http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=2883)?
> If the leak actually is in Resin, why isn't anybody else seeing this???
> Are we doing something unusual? (The only thing I could think of was
> ServletRequest implementations inside the application being dispatched,
> however I can't find any such implementations in use)
>
>  /Mattias Jiderhamn
>
>
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to