Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <27729799.6301286371353647.JavaMail.jira@thor>
Date: Wed, 6 Oct 2010 09:22:33 -0400 (EDT)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-2770) Initial size of ConcurrentCache
 depends on number of segments (available processors)
In-Reply-To: <7836548.5031286365830650.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918509#action_12918509 ] 

Jukka Zitting commented on JCR-2770:
------------------------------------

> What is the reason that you set the initial size to 1024?

The three-argument constructor (that's needed to enable LRU behaviour) requires some value there, and since there's no public constant for the default value I simply selected something that seemed reasonable. I chose a high value since I expected most practical cases to in any case use pretty large caches, and since environments with lots of processors would typically also have lots of available memory. I of course forgot to consider the fixed memory limits we specify for our test runs.

Essentially I just picked the value from my proverbial hat, so it's fine to change it to something different, especially if doing so helps prevent problems!

> Initial size of ConcurrentCache depends on number of segments (available processors)
> ------------------------------------------------------------------------------------
>
>                 Key: JCR-2770
>                 URL: https://issues.apache.org/jira/browse/JCR-2770
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>            Reporter: Marcel Reutegger
>            Priority: Minor
>             Fix For: 2.2.0
>
>         Attachments: JCR-2770.patch
>
>
> This causes a build failure on my machine. Tests run into an OOME because the initial memory footprint of a ConcurrentCache on my machine is 8k. Many of the tests keep references to some kind of repository objects (node, session, x-manager), which means ConcurrentCache instances  cannot be garbage collected immediately after a test run.
> I think the overall initial size of the cache should be independent of the number of segments. See proposed patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.