You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2004/12/14 14:21:55 UTC
[jira] Created: (JCR-29) Node.addNode() does not scale with increasing content
Node.addNode() does not scale with increasing content
-----------------------------------------------------
Key: JCR-29
URL: http://nagoya.apache.org/jira/browse/JCR-29
Project: Jackrabbit
Type: Bug
Environment: Jackrabbit SVN Rev. 111798
Reporter: Felix Meschberger
Priority: Blocker
With increasing repository content (and versions), the time to create new nodes increases. For example with around 6500 nodes and 33500 properties, it takes around 3 seconds (!) to just add one single node !
When attaching to the application with a Debugger and delibaretly suspending the VM, this stack trace is displayed all the times :
[ changing internals of access List iterator ]
PersistentNodeState(NodeState).getChildNodeEntries(String) line: 362
PersistentNode.getName() line: 84
PersistentVersionManager.getVersion(String) line: 278
VersionManager.getVersion(String) line: 304
VersionItemStateProvider.getNodeState(NodeId) line: 124
VersionItemStateProvider.hasPropertyState(PropertyId) line: 154
VersionItemStateProvider.hasItemState(ItemId) line: 174
SessionItemStateManager.getItemState(ItemId) line: 246
ItemManager.createItemInstance(ItemId) line: 563
ItemManager.getItem(ItemId) line: 332
NodeImpl.getProperty(QName) line: 876
NodeImpl.hasProperty(QName) line: 893
NodeImpl.safeIsCheckedOut() line: 2515
NodeImpl.internalAddChildNode(QName, NodeTypeImpl, String) line: 527
NodeImpl.internalAddNode(String, NodeTypeImpl, String) line: 475
NodeImpl.internalAddNode(String, NodeTypeImpl) line: 436
NodeImpl.addNode(String, String) line: 1145
...
It seems, that virtual item state providers are asked for whatever property is looked for and this in return calls into the version handler, which loops over some child entries (currently around 1100 entries) to find one single entry with a given UUID.
Besides the latter not being optimal and certainly not scaling, the former has its problems in its own right.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (JCR-29) Node.addNode() does not scale with increasing content
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-29?page=all ]
Stefan Guggisberg closed JCR-29:
--------------------------------
closing resolved issue
> Node.addNode() does not scale with increasing content
> -----------------------------------------------------
>
> Key: JCR-29
> URL: http://issues.apache.org/jira/browse/JCR-29
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit SVN Rev. 111798
> Reporter: Felix Meschberger
> Assignee: Tobias Strasser
> Priority: Blocker
>
> With increasing repository content (and versions), the time to create new nodes increases. For example with around 6500 nodes and 33500 properties, it takes around 3 seconds (!) to just add one single node !
> When attaching to the application with a Debugger and delibaretly suspending the VM, this stack trace is displayed all the times :
> [ changing internals of access List iterator ]
> PersistentNodeState(NodeState).getChildNodeEntries(String) line: 362
> PersistentNode.getName() line: 84
> PersistentVersionManager.getVersion(String) line: 278
> VersionManager.getVersion(String) line: 304
> VersionItemStateProvider.getNodeState(NodeId) line: 124
> VersionItemStateProvider.hasPropertyState(PropertyId) line: 154
> VersionItemStateProvider.hasItemState(ItemId) line: 174
> SessionItemStateManager.getItemState(ItemId) line: 246
> ItemManager.createItemInstance(ItemId) line: 563
> ItemManager.getItem(ItemId) line: 332
> NodeImpl.getProperty(QName) line: 876
> NodeImpl.hasProperty(QName) line: 893
> NodeImpl.safeIsCheckedOut() line: 2515
> NodeImpl.internalAddChildNode(QName, NodeTypeImpl, String) line: 527
> NodeImpl.internalAddNode(String, NodeTypeImpl, String) line: 475
> NodeImpl.internalAddNode(String, NodeTypeImpl) line: 436
> NodeImpl.addNode(String, String) line: 1145
> ...
> It seems, that virtual item state providers are asked for whatever property is looked for and this in return calls into the version handler, which loops over some child entries (currently around 1100 entries) to find one single entry with a given UUID.
> Besides the latter not being optimal and certainly not scaling, the former has its problems in its own right.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-29) Node.addNode() does not scale with increasing content
Posted by "Tobias Strasser (JIRA)" <ji...@apache.org>.
[ http://nagoya.apache.org/jira/browse/JCR-29?page=history ]
Tobias Strasser resolved JCR-29:
--------------------------------
Resolution: Fixed
should be fast and more scaleable since last reorganization of versioning (r123112)
> Node.addNode() does not scale with increasing content
> -----------------------------------------------------
>
> Key: JCR-29
> URL: http://nagoya.apache.org/jira/browse/JCR-29
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit SVN Rev. 111798
> Reporter: Felix Meschberger
> Assignee: Tobias Strasser
> Priority: Blocker
>
> With increasing repository content (and versions), the time to create new nodes increases. For example with around 6500 nodes and 33500 properties, it takes around 3 seconds (!) to just add one single node !
> When attaching to the application with a Debugger and delibaretly suspending the VM, this stack trace is displayed all the times :
> [ changing internals of access List iterator ]
> PersistentNodeState(NodeState).getChildNodeEntries(String) line: 362
> PersistentNode.getName() line: 84
> PersistentVersionManager.getVersion(String) line: 278
> VersionManager.getVersion(String) line: 304
> VersionItemStateProvider.getNodeState(NodeId) line: 124
> VersionItemStateProvider.hasPropertyState(PropertyId) line: 154
> VersionItemStateProvider.hasItemState(ItemId) line: 174
> SessionItemStateManager.getItemState(ItemId) line: 246
> ItemManager.createItemInstance(ItemId) line: 563
> ItemManager.getItem(ItemId) line: 332
> NodeImpl.getProperty(QName) line: 876
> NodeImpl.hasProperty(QName) line: 893
> NodeImpl.safeIsCheckedOut() line: 2515
> NodeImpl.internalAddChildNode(QName, NodeTypeImpl, String) line: 527
> NodeImpl.internalAddNode(String, NodeTypeImpl, String) line: 475
> NodeImpl.internalAddNode(String, NodeTypeImpl) line: 436
> NodeImpl.addNode(String, String) line: 1145
> ...
> It seems, that virtual item state providers are asked for whatever property is looked for and this in return calls into the version handler, which loops over some child entries (currently around 1100 entries) to find one single entry with a given UUID.
> Besides the latter not being optimal and certainly not scaling, the former has its problems in its own right.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-29) Node.addNode() does not scale with increasing content
Posted by "Tobias Strasser (JIRA)" <ji...@apache.org>.
[ http://nagoya.apache.org/jira/browse/JCR-29?page=history ]
Tobias Strasser reassigned JCR-29:
----------------------------------
Assign To: Tobias Strasser
yes, this i'm aware to this problem...
> Node.addNode() does not scale with increasing content
> -----------------------------------------------------
>
> Key: JCR-29
> URL: http://nagoya.apache.org/jira/browse/JCR-29
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit SVN Rev. 111798
> Reporter: Felix Meschberger
> Assignee: Tobias Strasser
> Priority: Blocker
>
> With increasing repository content (and versions), the time to create new nodes increases. For example with around 6500 nodes and 33500 properties, it takes around 3 seconds (!) to just add one single node !
> When attaching to the application with a Debugger and delibaretly suspending the VM, this stack trace is displayed all the times :
> [ changing internals of access List iterator ]
> PersistentNodeState(NodeState).getChildNodeEntries(String) line: 362
> PersistentNode.getName() line: 84
> PersistentVersionManager.getVersion(String) line: 278
> VersionManager.getVersion(String) line: 304
> VersionItemStateProvider.getNodeState(NodeId) line: 124
> VersionItemStateProvider.hasPropertyState(PropertyId) line: 154
> VersionItemStateProvider.hasItemState(ItemId) line: 174
> SessionItemStateManager.getItemState(ItemId) line: 246
> ItemManager.createItemInstance(ItemId) line: 563
> ItemManager.getItem(ItemId) line: 332
> NodeImpl.getProperty(QName) line: 876
> NodeImpl.hasProperty(QName) line: 893
> NodeImpl.safeIsCheckedOut() line: 2515
> NodeImpl.internalAddChildNode(QName, NodeTypeImpl, String) line: 527
> NodeImpl.internalAddNode(String, NodeTypeImpl, String) line: 475
> NodeImpl.internalAddNode(String, NodeTypeImpl) line: 436
> NodeImpl.addNode(String, String) line: 1145
> ...
> It seems, that virtual item state providers are asked for whatever property is looked for and this in return calls into the version handler, which loops over some child entries (currently around 1100 entries) to find one single entry with a given UUID.
> Besides the latter not being optimal and certainly not scaling, the former has its problems in its own right.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira