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" <r...@teeuwen.be> 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 > >
