From dev-return-9888-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Thu Nov 30 17:14:49 2006 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 77088 invoked from network); 30 Nov 2006 17:14:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Nov 2006 17:14:49 -0000 Received: (qmail 27608 invoked by uid 500); 30 Nov 2006 17:14:57 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 27579 invoked by uid 500); 30 Nov 2006 17:14:57 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 27568 invoked by uid 99); 30 Nov 2006 17:14:56 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Nov 2006 09:14:56 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Nov 2006 09:14:47 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id D036C7142EC for ; Thu, 30 Nov 2006 09:14:23 -0800 (PST) Message-ID: <23111512.1164906863850.JavaMail.jira@brutus> Date: Thu, 30 Nov 2006 09:14:23 -0800 (PST) From: "Thomas Mueller (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Updated: (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 X-Virus-Checked: Checked by ClamAV on apache.org [ http://issues.apache.org/jira/browse/JCR-619?page=all ] Thomas Mueller updated JCR-619: ------------------------------- Attachment: cacheManager7.txt 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. > 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, cacheManager6.txt, cacheManager7.txt, stack.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