Hey Thomas, Ok perfect, laying an oak:QueryIndexDefinition on propertyNames jcr:primaryType and declaringNodeTypes rep:ACL solved the issue. I presumed there already was an index for all the existing jcr:primaryTypes :), not that you have to specifically have them in the declaringNodeTypes
Thanks! Roy > On 18 Oct 2016, at 16:53, Thomas Mueller <[email protected]> wrote: > > Hi, > >> I really don¹t see the reason why this could be such a hard query > > > Who said it's a hard query? :-) > > Is the problem performance, or is the problem that you get an exception? > > > If the problem is performance, then you need an index on the node type > rep:ACL. > > If the problem is the exception: In your case the query engine is > configured to fail the queries (the reason is written in the exception > message). You can change the limit using the JMX bean > "QueryEngineSettings". The default is Long.MAX_VALUE (virtually no limit) > by the way. > > Regards, > Thomas > > > > On 18/10/16 16:44, "Roy Teeuwen" <[email protected]> wrote: > >> Hello all, >> >> I got a problem in oak concerning query performance for the following >> simple queries >> >> SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([/content]) >> SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([/var]) >> >> I get the following exception: >> >> java.lang.UnsupportedOperationException: The query read or traversed more >> than 150000 nodes. To avoid affecting other tasks, processing was stopped. >> at >> org.apache.jackrabbit.oak.query.FilterIterators.checkReadLimit(FilterItera >> tors.java:66) >> at >> org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor.fetchNext(Cur >> sors.java:324) >> at >> org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor.next(Cursors. >> java:303) >> at >> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:40 >> 9) >> at >> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl. >> java:773) >> at >> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.ja >> va:798) >> at >> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.fetch(QueryResultImp >> l.java:181) >> at >> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.next(QueryResultImpl >> .java:207) >> at >> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.next(QueryResultImpl >> .java:170) >> at >> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$SynchronizedIterato >> r.next(SessionDelegate.java:694) >> at >> org.apache.jackrabbit.oak.jcr.query.PrefetchIterator.next(PrefetchIterator >> .java:97) >> at >> org.apache.jackrabbit.commons.iterator.RangeIteratorAdapter.next(RangeIter >> atorAdapter.java:152) >> at >> org.apache.jackrabbit.commons.iterator.RangeIteratorDecorator.next(RangeIt >> eratorDecorator.java:92) >> at >> org.apache.jackrabbit.commons.iterator.NodeIteratorAdapter.nextNode(NodeIt >> eratorAdapter.java:80) >> at >> biz.netcentric.cq.tools.actool.helper.QueryHelper.getNodes(QueryHelper.jav >> a:128) >> at >> biz.netcentric.cq.tools.actool.helper.QueryHelper.getRepPolicyNodes(QueryH >> elper.java:90) >> at >> biz.netcentric.cq.tools.actool.dumpservice.impl.DumpserviceImpl.getACLDump >> Beans(DumpserviceImpl.java:399) >> >> Of course there is an oak:index on jcr:primaryType, so I really don¹t see >> the reason why this could be such a hard query to search for nodes under >> a path that are of type rep:ACL? >> (If you want more background, this query is used in the netcentric AC >> Tool to make a dump of all the existing rep policy ACL nodes) >> >> Greetings, >> Roy >> >> >
