jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (JCR-619) CacheManager (Memory Management in Jackrabbit)
Date Mon, 13 Nov 2006 11:09:39 GMT
     [ http://issues.apache.org/jira/browse/JCR-619?page=all ]

Stefan Guggisberg reopened JCR-619:
-----------------------------------

             
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.



> CacheManager (Memory Management in Jackrabbit)
> ----------------------------------------------
>
>                 Key: JCR-619
>                 URL: http://issues.apache.org/jira/browse/JCR-619
>             Project: Jackrabbit
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 1.1
>            Reporter: Thomas Mueller
>         Assigned To: Tobias Bocanegra
>             Fix For: 1.2
>
>         Attachments: cacheManager.txt, cacheManager2.txt
>
>
> 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

-- 
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

        

Mime
View raw message