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 <muel...@adobe.com> 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" <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
>> 
>> 
> 

Reply via email to