[
https://issues.apache.org/jira/browse/OAK-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565190#comment-13565190
]
Marcel Reutegger commented on OAK-333:
--------------------------------------
bq. similar to the randomly distributed node ids of Jackrabbit 2.x
It depends on the node structure. The most frequent problem pattern I saw in
the past where nodes with a couple of hundres child nodes. We always said
that's fine and you would only get into trouble when you have thousands of
nodes. But as experience showed that's not 100% correct. In Jackrabbit 2.x this
indeed results in hundres of random I/O because of the random UUIDs of the
child nodes. With the proposed hash of the parent path that's not the case. The
key (hash) to look up the child nodes is unique. The remaining problem is where
those nodes are stored on disk. But I guess that's something we cannot control
anyway if we depend on a 3rd party storage mechanism like MongoDB or H2.
bq. <hashOfParentPath>
Yes, I'd use SHA-1.
> 1000 character path limit in MongoMK
> ------------------------------------
>
> Key: OAK-333
> URL: https://issues.apache.org/jira/browse/OAK-333
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
> Affects Versions: 0.5
> Reporter: Mete Atamel
> Assignee: Mete Atamel
> Priority: Minor
> Attachments: OAK-333.patch
>
>
> In an infinite loop try to add nodes one under another to have N0/N1/N2...NN.
> At some point, the current parent node will not be found and the current
> commit will fail. I think this happens when the path length exceeds 1000
> characters. Is this enough for a path? I was able to create this way only 222
> levels in the tree (and my node names were really short N1, N2 ...)
> There's an automated tests for this: NodeExistsCommandMongoTest.testTreeDepth
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
