Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.1
    • Component/s: jackrabbit-core
    • Labels:
      None

      Description

      Jackrabbit can run out of memory because the the combined size of the various caches is not managed. The biggest problem (for me) is the combined size of the o.a.j.core.state.MLRUItemStateCache caches. Each session seems to create a few of those caches, and each one is limited to 4 MB by default.

      I have implemented a dynamic (cache-) memory management service that distributes a fixed amount of memory dynamically to all those caches.

      Here is the patch

      1. jackrabbit-cachemanager-config.patch
        5 kB
        Jaka Jaksic
      2. cacheManager7.txt
        2 kB
        Thomas Mueller
      3. stack.txt
        41 kB
        Xiaohua Lu
      4. cacheManager6.txt
        2 kB
        Thomas Mueller
      5. cacheManager5.txt
        41 kB
        Thomas Mueller
      6. cacheManager2.txt
        15 kB
        Thomas Mueller
      7. cacheManager.txt
        15 kB
        Thomas Mueller

        Issue Links

          Activity

          Hide
          Thomas Mueller added a comment -

          Hi,

          > Is it possible to use the Caching softwares on top of Jackrabbit

          Yes, sure. Maybe you want to cache on the application side.

          Show
          Thomas Mueller added a comment - Hi, > Is it possible to use the Caching softwares on top of Jackrabbit Yes, sure. Maybe you want to cache on the application side.
          Hide
          Samba Siva Rao Kolusu added a comment - - edited

          I would like to use the distributed Caching capabilities of the above mentioned Caching softwares which are proven and can handle hundreds of GB of in-memory or disk cache distributed over the network across dozens of computers.
          Actually I want to use the Content repository in a distributed environment with some master servers (load balanced to cater the failover scenario) mapping the content workspace locations across the network depending on some rules defined during the repository configuration. The The mapping information is replicated across the master servers and the content is spread across several clients(content on each client node is further replicated to siblings to address failover).

          In such a complex scenario, I would prefer to use a well known and proven Caching software to handle the job. And if the Jackrabbit cache is aimed at doing that my question is would it not be a duplicate effort when there are some very efficient caching libraries available and are standards compliant? Or Is it not possible to have a pluggable Cache implementations for use with Jackrabbit?

          Or may be I might have misunderstood some thing ---- Is it possible to use the Caching softwares on top of Jackrabbit, with out bothering about the jackrabbit's internal cache implementation?

          I just found out that a similar work is going on in Jackrabbit and a discussion may be related to JCR-872

          Show
          Samba Siva Rao Kolusu added a comment - - edited I would like to use the distributed Caching capabilities of the above mentioned Caching softwares which are proven and can handle hundreds of GB of in-memory or disk cache distributed over the network across dozens of computers. Actually I want to use the Content repository in a distributed environment with some master servers (load balanced to cater the failover scenario) mapping the content workspace locations across the network depending on some rules defined during the repository configuration. The The mapping information is replicated across the master servers and the content is spread across several clients(content on each client node is further replicated to siblings to address failover). In such a complex scenario, I would prefer to use a well known and proven Caching software to handle the job. And if the Jackrabbit cache is aimed at doing that my question is would it not be a duplicate effort when there are some very efficient caching libraries available and are standards compliant? Or Is it not possible to have a pluggable Cache implementations for use with Jackrabbit? Or may be I might have misunderstood some thing ---- Is it possible to use the Caching softwares on top of Jackrabbit, with out bothering about the jackrabbit's internal cache implementation? I just found out that a similar work is going on in Jackrabbit and a discussion may be related to JCR-872
          Hide
          Thomas Mueller added a comment -

          > use Apache Java Caching System or some other caching library like ehCache or JBoss cache
          Why do you like to have this feature?

          Show
          Thomas Mueller added a comment - > use Apache Java Caching System or some other caching library like ehCache or JBoss cache Why do you like to have this feature?
          Hide
          Samba Siva Rao Kolusu added a comment -

          Is there a way to use Apache Java Caching System or some other caching library like ehCache or JBoss cache with Jackrabit? If not, Can we expect this possibility in the near future ?

          Rather an abstraction over the JCache(JSR-107) allowing to plug in any cache manager that implements the specification would be very good step ahead.

          Show
          Samba Siva Rao Kolusu added a comment - Is there a way to use Apache Java Caching System or some other caching library like ehCache or JBoss cache with Jackrabit? If not, Can we expect this possibility in the near future ? Rather an abstraction over the JCache(JSR-107) allowing to plug in any cache manager that implements the specification would be very good step ahead.
          Hide
          Jaka Jaksic added a comment -

          I have created a really simple and straightforward patch (jackrabbit-cachemanager-config.patch) which enables reaching the CacheManager instance through RepositoryImpl object and setting all three of its memory parameters. The memory parameters are no longer static constants, but instance fields getting initial values from constants (so the default behavior doesn't change).

          Could this patch or something alike be included in a future release?

          (It would also be nice to be able to set these parameters via configuration files, but that should probably be implemented by someone close to the project.)

          Show
          Jaka Jaksic added a comment - I have created a really simple and straightforward patch (jackrabbit-cachemanager-config.patch) which enables reaching the CacheManager instance through RepositoryImpl object and setting all three of its memory parameters. The memory parameters are no longer static constants, but instance fields getting initial values from constants (so the default behavior doesn't change). Could this patch or something alike be included in a future release? (It would also be nice to be able to set these parameters via configuration files, but that should probably be implemented by someone close to the project.)
          Hide
          Jaka Jaksic added a comment -

          > private static final long MAX_MEMORY = 16 * 1024 * 1024;

          If I understand the CacheManager source correctly, the maximum size for all caches is hardcoded to 16 megabytes and there's no way to change that other than by changing the source. Now, while this is still a lot better than having no upper limit at all and risk running out of memory if you have many workspaces, it would be nice if this as well as other CacheManager parameters were configurable. It's just a waste running Jackrabbit on a server with gigabytes of memory and only using 16 megs for cache...

          Show
          Jaka Jaksic added a comment - > private static final long MAX_MEMORY = 16 * 1024 * 1024; If I understand the CacheManager source correctly, the maximum size for all caches is hardcoded to 16 megabytes and there's no way to change that other than by changing the source. Now, while this is still a lot better than having no upper limit at all and risk running out of memory if you have many workspaces, it would be nice if this as well as other CacheManager parameters were configurable. It's just a waste running Jackrabbit on a server with gigabytes of memory and only using 16 megs for cache...
          Hide
          Stefan Guggisberg added a comment -

          applied patch cacheManager7.txt (svn r481196).

          xiaohua confirmed that it solved the latest deadlock issue.

          Show
          Stefan Guggisberg added a comment - applied patch cacheManager7.txt (svn r481196). xiaohua confirmed that it solved the latest deadlock issue.
          Hide
          Thomas Mueller added a comment -

          I have a patch for the Java level deadlock problem. Now the method touch() is no longer synchronized on the cache. However, inside touch() the cache could shrink, and this is still synchronized. Also fixed is a problem in shrinkIfRequired: this method called touch() which could theoretically cause another shrinkIfRequired call.

          Show
          Thomas Mueller added a comment - I have a patch for the Java level deadlock problem. Now the method touch() is no longer synchronized on the cache. However, inside touch() the cache could shrink, and this is still synchronized. Also fixed is a problem in shrinkIfRequired: this method called touch() which could theoretically cause another shrinkIfRequired call.
          Hide
          Xiaohua Lu added a comment -

          I managed to reproduce the deadlock with 2 concurrent query. both query are select all category nodes.

          the test data is the same as before. The definition of data as as following :

          <nt = 'http://www.jcp.org/jcr/nt/1.0'>
          <mix = 'http://www.jcp.org/jcr/mix/1.0'>
          <mvn = 'http://maven.net/jcr/mock'>
          <mvnnt = 'http://maven.net/jcr/nt/mock'>

          [mvnnt:categoryHierarchyNode] > nt:base

          [mvnnt:category] > mvnnt:categoryHierarchyNode, mix:referenceable

          • mvn:description (string)
          • mvn:content (reference) multiple
            + * (mvnnt:categoryHierarchyNode)

          — note : the content field will point to file node and it is not used in this test.

          the query both threads are trying to perform is

          //element (*, mvnnt:category)

          – note : The query returned very quickly and the deadlock happened when both threads tried to iterate through the NoteIterator to make sure the returned result are of type mvnnt:category.

          The jstack output is as followings :

          Thread t@3847: (state = BLOCKED)

          • org.apache.jackrabbit.core.state.CacheManager.cacheAccessed() @bci=18, line=77 (Interpreted frame)
          • org.apache.jackrabbit.core.state.MLRUItemStateCache.touch() @bci=34, line=222 (Compiled frame)
          • org.apache.jackrabbit.core.state.MLRUItemStateCache.retrieve(org.apache.jackrabbit.core.ItemId) @bci=8, line=97 (Compiled frame)
          • org.apache.jackrabbit.core.state.ItemStateReferenceCache.retrieve(org.apache.jackrabbit.core.ItemId) @bci=5, line=99 (Compiled frame)
          • org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=54, line=233 (Compiled frame)
          • org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=56, line=165 (Compiled frame)
          • org.apache.jackrabbit.core.ItemManager.createItemInstance(org.apache.jackrabbit.core.ItemId) @bci=5, line=462 (Compiled frame)
          • org.apache.jackrabbit.core.ItemManager.getItem(org.apache.jackrabbit.core.ItemId) @bci=63, line=320 (Compiled frame)
          • org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.fetchNext() @bci=46, line=194 (Compiled frame)
          • org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.nextNodeImpl() @bci=21, line=103 (Compiled frame)
          • net.maven.cr.test.PerformanceQueryTest$ListCategoriesQueryTestContext.verify(javax.jcr.NodeIterator) @bci=25 (Interpreted frame)
          • net.maven.cr.test.PerformanceQueryTest.timingQuery(net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=34 (Interpreted frame)
          • net.maven.cr.test.PerformanceQueryTest.access$100(net.maven.cr.test.PerformanceQueryTest, net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=2 (Interpreted frame)
          • net.maven.cr.test.PerformanceQueryTest$TimedQueryTest.run() @bci=32 (Interpreted frame)

          Thread t@4099: (state = BLOCKED)

          • org.apache.jackrabbit.core.state.MLRUItemStateCache.getMemoryUsed() @bci=6, line=245 (Compiled frame; information may be imprecise)
          • org.apache.jackrabbit.core.state.CacheManager$CacheInfo.<init>(org.apache.jackrabbit.core.state.Cache) @bci=21, line=212 (Interpreted frame)
          • org.apache.jackrabbit.core.state.CacheManager.resizeAll() @bci=136, line=107 (Compiled frame)
          • org.apache.jackrabbit.core.state.CacheManager.cacheAccessed() @bci=40, line=81 (Interpreted frame)
          • org.apache.jackrabbit.core.state.MLRUItemStateCache.touch() @bci=34, line=222 (Compiled frame)
          • org.apache.jackrabbit.core.state.MLRUItemStateCache.cache(org.apache.jackrabbit.core.state.ItemState) @bci=8, line=129 (Compiled frame)
          • org.apache.jackrabbit.core.state.ItemStateReferenceCache.cache(org.apache.jackrabbit.core.state.ItemState) @bci=48, line=114 (Compiled frame)
          • org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(org.apache.jackrabbit.core.NodeId) @bci=31, line=99 (Compiled frame)
          • org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=47, line=150 (Compiled frame)
          • org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=54, line=233 (Compiled frame)
          • org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=56, line=165 (Compiled frame)
          • org.apache.jackrabbit.core.ItemManager.createItemInstance(org.apache.jackrabbit.core.ItemId) @bci=5, line=462 (Compiled frame)
          • org.apache.jackrabbit.core.ItemManager.getItem(org.apache.jackrabbit.core.ItemId) @bci=63, line=320 (Compiled frame)
          • org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.fetchNext() @bci=46, line=194 (Compiled frame)
          • org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.nextNodeImpl() @bci=21, line=103 (Compiled frame)
          • net.maven.cr.test.PerformanceQueryTest$ListCategoriesQueryTestContext.verify(javax.jcr.NodeIterator) @bci=25 (Interpreted frame)
          • net.maven.cr.test.PerformanceQueryTest.timingQuery(net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=34 (Interpreted frame)
          • net.maven.cr.test.PerformanceQueryTest.access$100(net.maven.cr.test.PerformanceQueryTest, net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=2 (Interpreted frame)
          • net.maven.cr.test.PerformanceQueryTest$TimedQueryTest.run() @bci=32 (Interpreted frame)
          Show
          Xiaohua Lu added a comment - I managed to reproduce the deadlock with 2 concurrent query. both query are select all category nodes. the test data is the same as before. The definition of data as as following : <nt = 'http://www.jcp.org/jcr/nt/1.0'> <mix = 'http://www.jcp.org/jcr/mix/1.0'> <mvn = 'http://maven.net/jcr/mock'> <mvnnt = 'http://maven.net/jcr/nt/mock'> [mvnnt:categoryHierarchyNode] > nt:base [mvnnt:category] > mvnnt:categoryHierarchyNode, mix:referenceable mvn:description (string) mvn:content (reference) multiple + * (mvnnt:categoryHierarchyNode) — note : the content field will point to file node and it is not used in this test. the query both threads are trying to perform is //element (*, mvnnt:category) – note : The query returned very quickly and the deadlock happened when both threads tried to iterate through the NoteIterator to make sure the returned result are of type mvnnt:category. The jstack output is as followings : Thread t@3847: (state = BLOCKED) org.apache.jackrabbit.core.state.CacheManager.cacheAccessed() @bci=18, line=77 (Interpreted frame) org.apache.jackrabbit.core.state.MLRUItemStateCache.touch() @bci=34, line=222 (Compiled frame) org.apache.jackrabbit.core.state.MLRUItemStateCache.retrieve(org.apache.jackrabbit.core.ItemId) @bci=8, line=97 (Compiled frame) org.apache.jackrabbit.core.state.ItemStateReferenceCache.retrieve(org.apache.jackrabbit.core.ItemId) @bci=5, line=99 (Compiled frame) org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=54, line=233 (Compiled frame) org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=56, line=165 (Compiled frame) org.apache.jackrabbit.core.ItemManager.createItemInstance(org.apache.jackrabbit.core.ItemId) @bci=5, line=462 (Compiled frame) org.apache.jackrabbit.core.ItemManager.getItem(org.apache.jackrabbit.core.ItemId) @bci=63, line=320 (Compiled frame) org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.fetchNext() @bci=46, line=194 (Compiled frame) org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.nextNodeImpl() @bci=21, line=103 (Compiled frame) net.maven.cr.test.PerformanceQueryTest$ListCategoriesQueryTestContext.verify(javax.jcr.NodeIterator) @bci=25 (Interpreted frame) net.maven.cr.test.PerformanceQueryTest.timingQuery(net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=34 (Interpreted frame) net.maven.cr.test.PerformanceQueryTest.access$100(net.maven.cr.test.PerformanceQueryTest, net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=2 (Interpreted frame) net.maven.cr.test.PerformanceQueryTest$TimedQueryTest.run() @bci=32 (Interpreted frame) Thread t@4099: (state = BLOCKED) org.apache.jackrabbit.core.state.MLRUItemStateCache.getMemoryUsed() @bci=6, line=245 (Compiled frame; information may be imprecise) org.apache.jackrabbit.core.state.CacheManager$CacheInfo.<init>(org.apache.jackrabbit.core.state.Cache) @bci=21, line=212 (Interpreted frame) org.apache.jackrabbit.core.state.CacheManager.resizeAll() @bci=136, line=107 (Compiled frame) org.apache.jackrabbit.core.state.CacheManager.cacheAccessed() @bci=40, line=81 (Interpreted frame) org.apache.jackrabbit.core.state.MLRUItemStateCache.touch() @bci=34, line=222 (Compiled frame) org.apache.jackrabbit.core.state.MLRUItemStateCache.cache(org.apache.jackrabbit.core.state.ItemState) @bci=8, line=129 (Compiled frame) org.apache.jackrabbit.core.state.ItemStateReferenceCache.cache(org.apache.jackrabbit.core.state.ItemState) @bci=48, line=114 (Compiled frame) org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(org.apache.jackrabbit.core.NodeId) @bci=31, line=99 (Compiled frame) org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=47, line=150 (Compiled frame) org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=54, line=233 (Compiled frame) org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=56, line=165 (Compiled frame) org.apache.jackrabbit.core.ItemManager.createItemInstance(org.apache.jackrabbit.core.ItemId) @bci=5, line=462 (Compiled frame) org.apache.jackrabbit.core.ItemManager.getItem(org.apache.jackrabbit.core.ItemId) @bci=63, line=320 (Compiled frame) org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.fetchNext() @bci=46, line=194 (Compiled frame) org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.nextNodeImpl() @bci=21, line=103 (Compiled frame) net.maven.cr.test.PerformanceQueryTest$ListCategoriesQueryTestContext.verify(javax.jcr.NodeIterator) @bci=25 (Interpreted frame) net.maven.cr.test.PerformanceQueryTest.timingQuery(net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=34 (Interpreted frame) net.maven.cr.test.PerformanceQueryTest.access$100(net.maven.cr.test.PerformanceQueryTest, net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=2 (Interpreted frame) net.maven.cr.test.PerformanceQueryTest$TimedQueryTest.run() @bci=32 (Interpreted frame)
          Hide
          Stefan Guggisberg added a comment -

          reopening based on xiaohua's feed back (potential dead lock)

          Show
          Stefan Guggisberg added a comment - reopening based on xiaohua's feed back (potential dead lock)
          Hide
          Xiaohua Lu added a comment -

          I have been running a concurrent test on Nov. 28th code base. A deadlock has been encouterred. The setup of the test is :
          1. 6000 file nodes flat under root node
          2. 900 category nodes, three level deep under root node
          3. 50 concurrent thread, each one perform one of the four queries :
          3.1 select all file nodes
          3.2 select all category nodes
          3.3 select file nodes by file property
          3.4 select category nodes by category property

          The tests only involved query, no add/delete/update are included. From the jstack.txt attached, you can see a few threads are blocking each other, it looks similar to what Tom reported a few weeks ago.

          Show
          Xiaohua Lu added a comment - I have been running a concurrent test on Nov. 28th code base. A deadlock has been encouterred. The setup of the test is : 1. 6000 file nodes flat under root node 2. 900 category nodes, three level deep under root node 3. 50 concurrent thread, each one perform one of the four queries : 3.1 select all file nodes 3.2 select all category nodes 3.3 select file nodes by file property 3.4 select category nodes by category property The tests only involved query, no add/delete/update are included. From the jstack.txt attached, you can see a few threads are blocking each other, it looks similar to what Tom reported a few weeks ago.
          Hide
          Stefan Guggisberg added a comment -

          applied patch cacheManager6.txt (svn r475735)

          Show
          Stefan Guggisberg added a comment - applied patch cacheManager6.txt (svn r475735)
          Hide
          Stefan Guggisberg added a comment -

          reopening since the current implementation may lead to Java level deadlocks, as thomas pointed out.

          such dead locks occasionally occur when running the maven tests.

          Show
          Stefan Guggisberg added a comment - reopening since the current implementation may lead to Java level deadlocks, as thomas pointed out. such dead locks occasionally occur when running the maven tests.
          Hide
          Thomas Mueller added a comment -

          A Java level deadlock could occur with the current CacheManager, if:

          Thread 1: CacheManager.resizeAll(holding a lock on the CacheManager) calls Cache.setMaxMemorySize (which tries to lock MLRUItemStateCache.cache)

          Thread 2: From the same object, MLRUItemStateCache.dispose (holding a lock on MLRUItemStateCache.cache) calls CacheManager.disposeCache (which tries to lock CacheManager)

          I made a patch, where CacheManager.disposeCache is not synchronized on the CacheManager. Instead, it synchronizes on the caches HashMap, where it removes the object (so that modifications to the caches map are synchronized, as this is needed). CacheManager.add now also synchronizes on the caches map.

          This should solve the problem.

          Show
          Thomas Mueller added a comment - A Java level deadlock could occur with the current CacheManager, if: Thread 1: CacheManager.resizeAll(holding a lock on the CacheManager) calls Cache.setMaxMemorySize (which tries to lock MLRUItemStateCache.cache) Thread 2: From the same object, MLRUItemStateCache.dispose (holding a lock on MLRUItemStateCache.cache) calls CacheManager.disposeCache (which tries to lock CacheManager) I made a patch, where CacheManager.disposeCache is not synchronized on the CacheManager. Instead, it synchronizes on the caches HashMap, where it removes the object (so that modifications to the caches map are synchronized, as this is needed). CacheManager.add now also synchronizes on the caches map. This should solve the problem.
          Hide
          Stefan Guggisberg added a comment -

          patch (cacheManager5.txt) committed, thanks for this contribution!

          Show
          Stefan Guggisberg added a comment - patch (cacheManager5.txt) committed, thanks for this contribution!
          Hide
          Thomas Mueller added a comment -

          Hi,

          This is the latest version of the CacheManager.

          As the CacheManager is not a singleton any more, the problem JCR-625 (Memory is not freed up when redeployed) should not appear with this patch.

          Also, the performance degradation found with the earlier versions of the CacheManager should be solved (now the caches are removed from the CacheManager when the session is closed). This has been tested with the unit tests so far on two machines.

          Thomas

          Show
          Thomas Mueller added a comment - Hi, This is the latest version of the CacheManager. As the CacheManager is not a singleton any more, the problem JCR-625 (Memory is not freed up when redeployed) should not appear with this patch. Also, the performance degradation found with the earlier versions of the CacheManager should be solved (now the caches are removed from the CacheManager when the session is closed). This has been tested with the unit tests so far on two machines. Thomas
          Hide
          Stefan Guggisberg added a comment -

          the patch caused a serious performance degradation.

          see http://www.nabble.com/Performance-degradation-in-current--trunk-t2608647.html

          i therefore temporarily reverted the changes from svn r471800.

          Show
          Stefan Guggisberg added a comment - the patch caused a serious performance degradation. see http://www.nabble.com/Performance-degradation-in-current--trunk-t2608647.html i therefore temporarily reverted the changes from svn r471800.
          Hide
          Tobias Bocanegra added a comment -

          Committed revision 471800.

          Show
          Tobias Bocanegra added a comment - Committed revision 471800.
          Hide
          Thomas Mueller added a comment -

          New version (log.debug instead of log.info, slower cache shrinking).

          Show
          Thomas Mueller added a comment - New version (log.debug instead of log.info, slower cache shrinking).
          Hide
          Thomas Mueller added a comment -

          Hi,

          I just made some more (long running) tests, and found some problems in the patch I submitted. The mechanism is working, but it shrinks the caches too quickly, and it prints too much log output (log.info instead of log.debug). I will fix those problems and submit a new patch. Sorry.

          Thomas

          Show
          Thomas Mueller added a comment - Hi, I just made some more (long running) tests, and found some problems in the patch I submitted. The mechanism is working, but it shrinks the caches too quickly, and it prints too much log output (log.info instead of log.debug). I will fix those problems and submit a new patch. Sorry. Thomas
          Hide
          Thomas Mueller added a comment -

          CacheManager

          Show
          Thomas Mueller added a comment - CacheManager

            People

            • Assignee:
              Stefan Guggisberg
              Reporter:
              Thomas Mueller
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development