[
https://issues.apache.org/jira/browse/OAK-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378929#comment-16378929
]
Chetan Mehrotra commented on OAK-7285:
--------------------------------------
First thing we can do is make "preferredPathElements" a Set instead of iterable
which would simply the code later and make it more clear
{code}
if (pitr.hasNext() && isAncestor(path, pitr.peek().getPath())) {
NodeStateEntry nextEntry = pitr.next();
String nextEntryName =
PathUtils.getName(nextEntry.getPath());
if (preferred && !Iterables.contains(preferredPathElements,
nextEntryName)) {
return endOfData();
}
return nextEntry;
}
{code}
Here {{nextEntryName}} would child node name of immediate or descendent child.
It may break flow if we have 2 preferred path elements and first has a child
Say preferred path is "a", "b"
{noformat}
a
a/x
a/x/y
b
{noformat}
Here iterator would break early and would not return 'b'. So we should only
check for preferred condition only if the path is immediate child path.
> Reindexing using --doc-traversal-mode can OOM while aggregation in some cases
> -----------------------------------------------------------------------------
>
> Key: OAK-7285
> URL: https://issues.apache.org/jira/browse/OAK-7285
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene, mongomk
> Affects Versions: 1.8.0
> Reporter: Vikas Saurabh
> Assignee: Vikas Saurabh
> Priority: Major
> Labels: candidate_oak_1_8
> Fix For: 1.9.0, 1.10
>
>
> {{--doc-traversal-mode}} works on the notion of {{preferred}} children which
> is computed using path fragments that form aggregate rules.
> The idea is reading through aggregated paths should avoid keeping non useful
> nodes (for path being currently indexed) in memory.
> But, currently, in case, say when there multiple preferred children -
> {{jcr:content}}, {{metadata}}, then an index defn indexing parent of a very
> deep tree root would try to read in the whole tree before concluding that it
> doesn't have preferred children
> e.g. with preferred list - {{jcr:content}} and {{metadata}} and index looking
> for {{jcr:content}} indexing following structure
> {noformat}
> + /path/being/indexed
> + very
> + very
> + very
> + deep
> + tree
> + /some-sibling
> {noformat}
> Currently, while looking for {{jcr:content}}, the code concludes that it
> doesn't exist only after reaching {{/some-sibling}} (or if number of children
> read of {{/path/being/indexed}} is >= num_preferred_children).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
