Actually Mark can you take a quick look at the class I sent and see if
it makes sense. I swapped juli with commons logging (which is in bin)
but now I am not sure this is necessary, this library may already be
loaded regardless of this filter.
E
---
Tomcat 5.5 version + log message when executed:
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to
Elli Albek wrote:
> Sorry Mark.
>
> Well this class loading scheme (context class loader -> static
> variable) sounds little like a bug.
Indeed.
> Thanks for that startup class. I think it will solve a problem that we
> have (using imageio). So you just add it as high up as possible in the
> ser
Sorry Mark.
Well this class loading scheme (context class loader -> static
variable) sounds little like a bug.
Thanks for that startup class. I think it will solve a problem that we
have (using imageio). So you just add it as high up as possible in the
server.xml hierarchy?
E
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark,
On 11/9/2009 6:47 PM, Mark Thomas wrote:
> Give this a go:
> http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
You gotta love Sun:
private static boolean defaultUseCaches = true
Elli Albek wrote:
> Thomas,
My given name is is Mark. Thomas is my family name.
> what is the issue with javax.imageio? Do they really use
> context class loader for loading static variables?
Yes. First call to most methods in that library trigger a call to
sun.awt.AppContext.getAppContext() whi
Thomas, what is the issue with javax.imageio? Do they really use
context class loader for loading static variables?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.a
:)
Mark
>
> Gerwood
>
> From: Mark Thomas [ma...@apache.org]
> Sent: Tuesday, 10 November 2009 10:48 AM
> To: Tomcat Users List
> Subject: Re: WebappClassLoader and undeploy
>
> Gerwood Stewart wrote:
>> Elli
>>
>> I understand most of this.
Mark
Thanks. I suppose I'd better get back to identifying the real problems then. :D
Gerwood
From: Mark Thomas [ma...@apache.org]
Sent: Tuesday, 10 November 2009 10:48 AM
To: Tomcat Users List
Subject: Re: WebappClassLoader and undeploy
Gerwood St
Gerwood Stewart wrote:
> Elli
>
> I understand most of this. I do several things such as forcing a GC before
> doing the heap dump, from what you are say this may not be enough?
> Either way I'm not looking for an instance of the class to simply be there
> I'm looking at the GC Roots.
>
> I al
Gerwood Stewart wrote:
> Mark
>
>> 2. Why would Tomcat be cleaning up the WebappLoader instance everytime
>> successfully but seems to 'hang-on' to the WebappClassLoader instance?
> My money is on it being JVM code rather than Tomcat code that is hanging
> onto the WebappClassLoader. Are you test
ughts?
Additionally I'm going to try and find a slightly old version of java and check
it's behaviour...
Gerwood
From: Elli Albek [e...@sustainlane.com]
Sent: Tuesday, 10 November 2009 9:52 AM
To: Tomcat Users List
Subject: Re: WebappClassLoade
day, 10 November 2009 9:07 AM
To: Tomcat Users List
Subject: Re: WebappClassLoader and undeploy
Gerwood Stewart wrote:
> Tomact seems to have retained 1 on the WebappClassLoader instances.
>
> I have two questions at this point:
>
> 1. From the Javadocs both WebappClassLoader and We
> From: Jorge Medina [mailto:jmed...@e-dialog.com]
> Subject: RE: WebappClassLoader and undeploy
>
> Does the JVM perform class unloading by default?
Usually. However, the JVM version and the choice of GC algorithm may make it
impossible to unload classes. For example, th
...@sustainlane.com]
Sent: Monday, November 09, 2009 5:53 PM
To: Tomcat Users List
Subject: Re: WebappClassLoader and undeploy
Managing class loaders is done in the JVM. Tomcat cannot force the JVM to
garbage collect class loaders, in the same way that it cannot force the JVM to
garbage collect
Managing class loaders is done in the JVM. Tomcat cannot force the JVM
to garbage collect class loaders, in the same way that it cannot force
the JVM to garbage collect any object.
If the class loader is unreachable, and all other objects that this
class loader provided are also unreachable, then t
Gerwood Stewart wrote:
> Tomact seems to have retained 1 on the WebappClassLoader instances.
>
> I have two questions at this point:
>
> 1. From the Javadocs both WebappClassLoader and WebappLoader are class
> loaders. What are the differences and why does Tomcat use both?
WebappClassLoader is t
I originally started down this path trying to find a memory leak (involving
commons-logging etc). I now have a more general question:
I've created an almost empty context. It contains 1 servlet which contains an
arraylist (just to create a large object that is easier to see in memory
graphs) an
18 matches
Mail list logo
