jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Strasser (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-29) Node.addNode() does not scale with increasing content
Date Tue, 28 Dec 2004 14:21:17 GMT
     [ 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


Mime
View raw message