You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2006/11/07 11:08:52 UTC
[jira] Created: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
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
Environment: No released version is affected, only trunk: svn revision 471800.
Reporter: Marcel Reutegger
Priority: Minor
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
Re: [jira] Commented: (JCR-625) Memory is not freed up when jackrabbit-server war is redeployed in tomcat
Posted by Stefan Guggisberg <st...@gmail.com>.
On 11/8/06, Thomas Mueller <th...@gmail.com> wrote:
> Hi,
>
> I agree, the CacheManager is an implementation detail and should not
> exposed to other components as much as possible. I hope that the
> CacheManager can be removed in the future, for me it is just a
> workaround for the memory problem.
>
> Unfortunately (and this is the root of the problem), there is not only
> one single cache instance per repository / session, but one cache per
> ItemStateManager. For me, the best design would be to have only one
> cache, because only in this way the LRU algorithm (or whatever other
unfortunately that wouldn't work. as i've mentioned earlier the different
caches have specific semantics, e.g. some have to make sure that there
exists only 1 ItemState instance per id per session...
cheers
stefan
> algorithm, maybe 2Q) can work like it should. One way would be to
> extend the key of a cache item to include the ItemStateManager it
> belongs to, but that would mean one more reference per cached object.
> Currently, I would be afraid to change the cache architecture like
> this, it would be not only much more work, but also more dangerous as
> I don't know the Jackrabbit codebase good enough so far. Also, it
> probably makes sense to wait until the SPI project is done.
>
> I will change the implementation to reduce the visibility of the
> CacheManager, so that it can be removed more easily later on.
>
> Thomas
>
Re: [jira] Commented: (JCR-625) Memory is not freed up when jackrabbit-server war is redeployed in tomcat
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
I agree, the CacheManager is an implementation detail and should not
exposed to other components as much as possible. I hope that the
CacheManager can be removed in the future, for me it is just a
workaround for the memory problem.
Unfortunately (and this is the root of the problem), there is not only
one single cache instance per repository / session, but one cache per
ItemStateManager. For me, the best design would be to have only one
cache, because only in this way the LRU algorithm (or whatever other
algorithm, maybe 2Q) can work like it should. One way would be to
extend the key of a cache item to include the ItemStateManager it
belongs to, but that would mean one more reference per cached object.
Currently, I would be afraid to change the cache architecture like
this, it would be not only much more work, but also more dangerous as
I don't know the Jackrabbit codebase good enough so far. Also, it
probably makes sense to wait until the SPI project is done.
I will change the implementation to reduce the visibility of the
CacheManager, so that it can be removed more easily later on.
Thomas
[jira] Updated: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ 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
[jira] Closed: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting closed JCR-625.
-----------------------------
> Memory is not freed up when jackrabbit-server war is redeployed in tomcat
> -------------------------------------------------------------------------
>
> Key: JCR-625
> URL: https://issues.apache.org/jira/browse/JCR-625
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Environment: No released version is affected, only trunk: svn revision 471800.
> Reporter: Marcel Reutegger
> Assignee: Thomas Mueller
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-625?page=comments#action_12447756 ]
Thomas Mueller commented on JCR-625:
------------------------------------
Obviously, this is really bad. It didn't help to make it a daemon thread, and to use a WeakHashMap. I will change the CacheManager: instead of being a singleton, the CacheManager will be associated with a PersistentManager (or Repository). And the thread must be stopped when the PersistentManager / Repository is closed. This should solve the problem. Unfortunately, it will be harder to avoid OutOfMemory if many repositories are open at the same time, but this is probably not that big a problem.
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
> Environment: No released version is affected, only trunk: svn revision 471800.
> Reporter: Marcel Reutegger
> Priority: Minor
>
> 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
[jira] Commented: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-625?page=comments#action_12447853 ]
Jukka Zitting commented on JCR-625:
-----------------------------------
I don't really like the idea of having to use a separate thread to do this. Can't the various caches just call the CacheManager whenever an object is placed in the cache. You can amortize the performance hit by requesting reallocation only every N caching operations. This structure would avoid the need to manage a separate thread.
Also, it would be cleaner if you passed around a factory object instead of the CacheManager. That would make it much easier to plug in alternative caching behaviours. Something like this:
public interface ItemStateCacheFactory {
ItemStateCache newItemStateCache();
}
and:
public class ManagedMLRUItemStateCacheFactory {
private final CacheManager manager;
public ManagedCacheFactory(CacheManager manager) {
this.manager = manager;
}
public ItemStateCache newItemStateCache() {
ItemStateCache cache = new MLRUItemStateCache();
manager.add(cache);
return 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
>
>
> 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
[jira] Commented: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-625?page=comments#action_12447841 ]
Thomas Mueller commented on JCR-625:
------------------------------------
Starting / stopping the CacheManager thread on demand would probably be a solution, I didn't think about this. The singleton pattern would still not work when using different class loaders. Also, configuring the cache size per repository is not possible. I made a patch to keep the cache managers in the RepositoryImpl. Unfortunately, this means adding it to many constructors. The test case with the jcr-server works now (the unit tests work as well).
> 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
> Environment: No released version is affected, only trunk: svn revision 471800.
> Reporter: Marcel Reutegger
> Priority: Minor
>
> 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
[jira] Commented: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-625?page=comments#action_12448082 ]
Jukka Zitting commented on JCR-625:
-----------------------------------
A simpler alternative to using the factory pattern would be to pull the instantiation of the cache as high up the call chain as possible. It would still be cleaner to pass the cache instance to an ItemStateManager than the CacheManager, since the manager is really a detail of the cache implementation and should not be exposed to other components like the ItemStatemanagers.
> 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
>
>
> 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
[jira] Updated: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-625?page=all ]
Jukka Zitting updated JCR-625:
------------------------------
Component/s: core
> 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
>
>
> 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
[jira] Resolved: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Mueller resolved JCR-625.
--------------------------------
Resolution: Fixed
Assignee: Thomas Mueller (was: Tobias Bocanegra)
As far as I know, this problem has been fixed since a long time. Please reopen if not.
> Memory is not freed up when jackrabbit-server war is redeployed in tomcat
> -------------------------------------------------------------------------
>
> Key: JCR-625
> URL: https://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
> Assignee: Thomas Mueller
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-625?page=comments#action_12447783 ]
Marcel Reutegger commented on JCR-625:
--------------------------------------
How about starting the background thread only when there are caches to manage? Or stop the background thread when there are no more caches to manage respectively?
> 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
> Environment: No released version is affected, only trunk: svn revision 471800.
> Reporter: Marcel Reutegger
> Priority: Minor
>
> 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
[jira] Commented: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-625?page=comments#action_12449305 ]
Thomas Mueller commented on JCR-625:
------------------------------------
The CacheManager slows a few things down at the moment, for example the unit tests. I found the problem: The caches are never disposed, and therefore the CacheManager sometimes has a lot of caches to manage (at one point in the unit test over 3000). Garbage collection will eventually reclaim the unused objects (the CacheManager uses a WeakHashMap), so this is not a memory problem. I will submit a patch later today.
> 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
> Assigned To: Tobias Bocanegra
> 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
[jira] Assigned: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-625?page=all ]
Tobias Bocanegra reassigned JCR-625:
------------------------------------
Assignee: Tobias Bocanegra
> 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
> Assigned To: Tobias Bocanegra
> 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
[jira] Updated: (JCR-625) Memory is not freed up when
jackrabbit-server war is redeployed in tomcat
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-625?page=all ]
Thomas Mueller updated JCR-625:
-------------------------------
Attachment: cacheManager3.txt
CacheManager in the RepositoryImpl
> 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
> Environment: No released version is affected, only trunk: svn revision 471800.
> Reporter: Marcel Reutegger
> Priority: Minor
> Attachments: cacheManager3.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