jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-625) Memory is not freed up when jackrabbit-server war is redeployed in tomcat
Date Thu, 09 Nov 2006 11:21:38 GMT
     [ http://issues.apache.org/jira/browse/JCR-625?page=all ]

Thomas Mueller updated JCR-625:

    Attachment: cacheManager4.txt


As requested by Jukka Zitting, I made a few changes to the cache manager. There is no new
functionality, and the current behaviour changed only very slightly:

Instead of passing the CacheManager to various constructors, now an ItemStateCacheFactory
is passed (this is a new interface, and there is a single new class implementing this interface,

Now the caches calls the CacheManager from time to time (each time a cache was accessed 128
more times). This is not done directly, but using a new interface CacheAccessListener. The
CacheManager is the only class implementing this interface. The CacheManager then checks if
it's time to resize the caches (this is done at most every second). There is no more cache
manager thread. The disadvantages are: The caches will not shrink if none of them is accessed,
or accessed infrequently. And there is a (very small) overhead on each cache access.

Again, for me the CacheManager is a workaround. I hope we can soon replace this with a (more)
unified cache. 


> Memory is not freed up when jackrabbit-server war is redeployed in tomcat
> -------------------------------------------------------------------------
>                 Key: JCR-625
>                 URL: http://issues.apache.org/jira/browse/JCR-625
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: core
>         Environment: No released version is affected, only trunk: svn revision 471800.
>            Reporter: Marcel Reutegger
>            Priority: Minor
>         Attachments: cacheManager3.txt, cacheManager4.txt
> This bug was introduced with the new CacheManager feature. See JCR-619.
> The CacheManager starts a new background thread which optimizes memory distribution every
second accross the various caches. When a jackrabbit repository is shutdown, this background
thread is still running and prevents the GC from collecting the classloader when jackrabbit
is deployed in a web application.
> Steps to reproduce:
> 1) build jackrabbit and jcr-server from trunk and deploy into a tomcat
> 2) touch the web.xml file of the jcr-server web app (this will force a redeployment)
> After step 2 two things may happen. Either:
> - The memory consumption increases because the CacheManager thread is not shutdown
> or
> - The CacheManager thread dies unexpectedly with a NullPointerException:
> Exception in thread "org.apache.jackrabbit.core.state.CacheManager" java.lang.NullPointerException
>         at org.apache.jackrabbit.core.state.CacheManager.run(CacheManager.java:90)
>         at java.lang.Thread.run(Unknown Source)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message