You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Torgeir Veimo <to...@netenviron.com> on 2009/12/17 06:18:00 UTC
permgen issues
I'm seeing some permgen issues with multiple redeploys under tomcat.
I've managed to fix dangling thread with derby using
DriverManager.getConnection("jdbc:derby:;shutdown=true");
but I'm still seeing some instances of threads named "Timer-14",
"Timer-"15" etc. I'm wondering if these can be instances of
org.apache.jackrabbit.spi.util.Timer? I see about three such threads
waiting while the application is running, but otherwise being idle.
after redeployment, a single one of these is still waiting.
Any clues to what can be happening here? I'm doing profiling with
visualgc on jdk1.6/mac with JR 2.0beta4, and derby PM
org.apache.jackrabbit.core.state.db.DerbyPersistenceManager
--
-Tor
Re: permgen issues
Posted by Torgeir Veimo <to...@netenviron.com>.
2010/1/5 Torgeir Veimo <to...@netenviron.com>:
> Bump. Does anyone have any insight into why the last timer instance hangs?
>
> 2009/12/17 Torgeir Veimo <to...@netenviron.com>:
>> 2009/12/17 Torgeir Veimo <to...@netenviron.com>:
>>> I'm seeing some permgen issues with multiple redeploys under tomcat.
>>> I've managed to fix dangling thread with derby using
>>>
>>> DriverManager.getConnection("jdbc:derby:;shutdown=true");
>>>
>>> but I'm still seeing some instances of threads named "Timer-14",
>>> "Timer-"15" etc. I'm wondering if these can be instances of
>>> org.apache.jackrabbit.spi.util.Timer? I see about three such threads
>>> waiting while the application is running, but otherwise being idle.
>>> after redeployment, a single one of these is still waiting.
>>>
>>> Any clues to what can be happening here?
>>
>> My repository is instantiated like thi;
>>
>> InputStream repositoryXml = servletContext.getResourceAsStream(configFile);
>> RepositoryConfig config = RepositoryConfig.create(repositoryXml,
>> repositoryPath);
>> repository = new TransientRepository(config);
>>
>> with only this code active, there are no Timers threads created, and
>> none hangs on webapp redeploy.
>>
>> If I add a session login & logout, then two Timer threads created, and
>> the second one of these hangs waiting on webapp redeploy.
>>
>> Session session = repository.login(new SimpleCredentials("admin", new
>> char[]{'a', 'd', 'm', 'i', 'n'}));
>> session.logout();
Tomcat 6.0.24 contains some interesting work in this area. This is the
log output after shutdown of my webapp, when redeploying. Most of
these looks like jackrabbit related, except for the cxf reference.
Jan 22, 2010 2:39:46 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[Timer-1] but has failed to stop it. This is very likely to create a
memory leak.
Jan 22, 2010 2:39:46 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[Timer-2] but has failed to stop it. This is very likely to create a
memory leak.
Jan 22, 2010 2:39:46 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[RMManager-Timer-1768049180] but has failed to stop it. This is very
likely to create a memory leak.
Jan 22, 2010 2:39:46 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@45fd24c1]) and a
value of type [org.apache.cxf.bus.CXFBusImpl] (value
[org.apache.cxf.bus.CXFBusImpl@6e781ecc]) but failed to remove it when
the web application was stopped. To prevent a memory leak, the
ThreadLocal has been forcibly removed.
Jan 22, 2010 2:39:46 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@102e1bbd]) and a
value of type [org.apache.jackrabbit.core.query.lucene.PerQueryCache]
(value [org.apache.jackrabbit.core.query.lucene.PerQueryCache@431f1d97])
but failed to remove it when the web application was stopped. To
prevent a memory leak, the ThreadLocal has been forcibly removed.
Jan 22, 2010 2:39:46 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@2fcfc6ee]) and a
value of type [org.apache.derby.iapi.services.context.ContextManager]
(value [org.apache.derby.iapi.services.context.ContextManager@36ed5ba6])
but failed to remove it when the web application was stopped. To
prevent a memory leak, the ThreadLocal has been forcibly removed.
Jan 22, 2010 2:39:46 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type
[org.apache.axis.utils.XMLUtils.ThreadLocalDocumentBuilder] (value
[org.apache.axis.utils.XMLUtils$ThreadLocalDocumentBuilder@46ea3050])
and a value of type [org.apache.xerces.jaxp.DocumentBuilderImpl]
(value [org.apache.xerces.jaxp.DocumentBuilderImpl@3909f88f]) but
failed to remove it when the web application was stopped. To prevent a
memory leak, the ThreadLocal has been forcibly removed.
Jan 22, 2010 2:39:46 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type
[org.apache.derby.iapi.sql.dictionary.TableDescriptor$1] (value
[org.apache.derby.iapi.sql.dictionary.TableDescriptor$1@3d9d918a]) and
a value of type [java.util.WeakHashMap] (value [{=null, =null, =null,
=null, =null, ={1}, ={2, 3, 4}, =null, =null, =null, =null, ={1},
={1}, ={1}, ={1, 2}, ={1}, =null, =null, ={1}, ={1}, ={2, 3, 4}, ={1},
={1}, =null, ={1, 2}, =null}]) but failed to remove it when the web
application was stopped. To prevent a memory leak, the ThreadLocal has
been forcibly removed.
Jan 22, 2010 2:39:46 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@102e1bbd]) and a
value of type [org.apache.jackrabbit.core.query.lucene.PerQueryCache]
(value [org.apache.jackrabbit.core.query.lucene.PerQueryCache@4580e541])
but failed to remove it when the web application was stopped. To
prevent a memory leak, the ThreadLocal has been forcibly removed.
--
-Tor
Re: permgen issues
Posted by Torgeir Veimo <to...@netenviron.com>.
Bump. Does anyone have any insight into why the last timer instance hangs?
2009/12/17 Torgeir Veimo <to...@netenviron.com>:
> 2009/12/17 Torgeir Veimo <to...@netenviron.com>:
>> I'm seeing some permgen issues with multiple redeploys under tomcat.
>> I've managed to fix dangling thread with derby using
>>
>> DriverManager.getConnection("jdbc:derby:;shutdown=true");
>>
>> but I'm still seeing some instances of threads named "Timer-14",
>> "Timer-"15" etc. I'm wondering if these can be instances of
>> org.apache.jackrabbit.spi.util.Timer? I see about three such threads
>> waiting while the application is running, but otherwise being idle.
>> after redeployment, a single one of these is still waiting.
>>
>> Any clues to what can be happening here?
>
> My repository is instantiated like thi;
>
> InputStream repositoryXml = servletContext.getResourceAsStream(configFile);
> RepositoryConfig config = RepositoryConfig.create(repositoryXml,
> repositoryPath);
> repository = new TransientRepository(config);
>
> with only this code active, there are no Timers threads created, and
> none hangs on webapp redeploy.
>
> If I add a session login & logout, then two Timer threads created, and
> the second one of these hangs waiting on webapp redeploy.
>
> Session session = repository.login(new SimpleCredentials("admin", new
> char[]{'a', 'd', 'm', 'i', 'n'}));
> session.logout();
>
>
> --
> -Tor
>
--
-Tor
Re: permgen issues
Posted by Torgeir Veimo <to...@netenviron.com>.
2009/12/17 Torgeir Veimo <to...@netenviron.com>:
> I'm seeing some permgen issues with multiple redeploys under tomcat.
> I've managed to fix dangling thread with derby using
>
> DriverManager.getConnection("jdbc:derby:;shutdown=true");
>
> but I'm still seeing some instances of threads named "Timer-14",
> "Timer-"15" etc. I'm wondering if these can be instances of
> org.apache.jackrabbit.spi.util.Timer? I see about three such threads
> waiting while the application is running, but otherwise being idle.
> after redeployment, a single one of these is still waiting.
>
> Any clues to what can be happening here?
My repository is instantiated like thi;
InputStream repositoryXml = servletContext.getResourceAsStream(configFile);
RepositoryConfig config = RepositoryConfig.create(repositoryXml,
repositoryPath);
repository = new TransientRepository(config);
with only this code active, there are no Timers threads created, and
none hangs on webapp redeploy.
If I add a session login & logout, then two Timer threads created, and
the second one of these hangs waiting on webapp redeploy.
Session session = repository.login(new SimpleCredentials("admin", new
char[]{'a', 'd', 'm', 'i', 'n'}));
session.logout();
--
-Tor