jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2770) Initial size of ConcurrentCache depends on number of segments (available processors)
Date Wed, 06 Oct 2010 12:16:33 GMT

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

Jukka Zitting commented on JCR-2770:

+1 Alternatively we could just set the initial size to the default 16 as the resize logic
shouldn't really affect performance to any notable degree.

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

View raw message