You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2010/10/06 13:50:30 UTC
[jira] Created: (JCR-2770) Initial size of ConcurrentCache depends
on number of segments (available processors)
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
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.
[jira] Commented: (JCR-2770) Initial size of ConcurrentCache
depends on number of segments (available processors)
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918501#action_12918501 ]
Marcel Reutegger commented on JCR-2770:
---------------------------------------
That was actually another point I noticed when I looked at the code. What is the reason that you set the initial size to 1024?
> 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.
[jira] Commented: (JCR-2770) Initial size of ConcurrentCache
depends on number of segments (available processors)
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918585#action_12918585 ]
Jukka Zitting commented on JCR-2770:
------------------------------------
I went ahead and changed the initial size of each cache segment from 1024 to 16. See revision 1005112.
> 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.
[jira] Commented: (JCR-2770) Initial size of ConcurrentCache
depends on number of segments (available processors)
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (JCR-2770) Initial size of ConcurrentCache depends
on number of segments (available processors)
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ 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.1.2
Issue Type: Bug (was: Improvement)
Merged to the 2.1 branch in revision 1026002.
> 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.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.
[jira] Updated: (JCR-2770) Initial size of ConcurrentCache depends
on number of segments (available processors)
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-2770:
-------------------------------
Resolution: Fixed
Assignee: Jukka Zitting
Status: Resolved (was: Patch Available)
Resolving as fixed.
> 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
> Assignee: Jukka Zitting
> 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.
[jira] Updated: (JCR-2770) Initial size of ConcurrentCache depends
on number of segments (available processors)
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (JCR-2770) Initial size of ConcurrentCache depends
on number of segments (available processors)
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger updated JCR-2770:
----------------------------------
Fix Version/s: 2.2.0
Status: Patch Available (was: Open)
> 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.
[jira] Commented: (JCR-2770) Initial size of ConcurrentCache
depends on number of segments (available processors)
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-2770) Initial size of ConcurrentCache
depends on number of segments (available processors)
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918535#action_12918535 ]
Marcel Reutegger commented on JCR-2770:
---------------------------------------
> three-argument constructor
ah, right. thanks, that explains it.
> 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.
[jira] Updated: (JCR-2770) Initial size of ConcurrentCache depends
on number of segments (available processors)
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger updated JCR-2770:
----------------------------------
Attachment: JCR-2770.patch
> 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.