Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <7307018.1163596658911.JavaMail.jira@brutus>
Date: Wed, 15 Nov 2006 05:17:38 -0800 (PST)
From: "Stefan Guggisberg (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Resolved: (JCR-619) CacheManager (Memory Management in
 Jackrabbit)
In-Reply-To: <6602807.1162551976602.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/JCR-619?page=all ]

Stefan Guggisberg resolved JCR-619.
-----------------------------------

    Resolution: Fixed

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

> 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: Stefan Guggisberg
>             Fix For: 1.2
>
>         Attachments: cacheManager.txt, cacheManager2.txt, cacheManager5.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