[ http://issues.apache.org/jira/browse/JCR-625?page=all ]
Thomas Mueller updated JCR-625:
-------------------------------
Attachment: cacheManager4.txt
Hi,
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, ManagedMLRUItemStateCacheFactory).
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.
Thomas
> 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
