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] Updated: (JCR-2770) Initial size of ConcurrentCache depends on number of segments (available processors)
Date Thu, 21 Oct 2010 15:30:15 GMT

     [ https://issues.apache.org/jira/browse/JCR-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jukka Zitting updated JCR-2770:
-------------------------------

    Fix Version/s: 2.0.3

And merged to the 2.0 branch in revision 1026027.

> 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: Bug
>          Components: jackrabbit-core
>            Reporter: Marcel Reutegger
>            Assignee: Jukka Zitting
>            Priority: Minor
>             Fix For: 2.0.3, 2.1.2, 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.


Mime
View raw message