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