You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Michael Dürig <md...@apache.org> on 2012/11/28 12:07:45 UTC

OOME with XPath query

Hi,

The following code results in an OOME for me [1] on the current trunk:

QueryManager qm = session.getWorkspace().getQueryManager();
Query q = qm.createQuery("/jcr:root/root//element(*)", Query.XPATH);
QueryResult r = q.execute();  // OOME here

The sub tree rooted at /root is "large" but none of its nodes has more 
than 100 direct child nodes. From what I could see, the amount of memory 
needed to execute the query grows aprox. linearly with the number of 
nodes in the sub tree.

Is that expected? I was under the impression that query results would be 
collected lazily. Does that sound a bell for anyone?

Any pointers to changes in the query engine which could have something 
to do with this are appreciated.

Michael



Re: OOME with XPath query

Posted by Michael Dürig <md...@apache.org>.
Hi,

It seems no one noticed this due to JCR-3472 [1]. With a tentative fix 
for that issue, 
org.apache.jackrabbit.core.query.lucene.LargeResultSetTest fails for me 
with an OOME.

Michael

[1] https://issues.apache.org/jira/browse/JCR-3472

On 28.11.12 11:07, Michael Dürig wrote:
>
> Hi,
>
> The following code results in an OOME for me [1] on the current trunk:
>
> QueryManager qm = session.getWorkspace().getQueryManager();
> Query q = qm.createQuery("/jcr:root/root//element(*)", Query.XPATH);
> QueryResult r = q.execute();  // OOME here
>
> The sub tree rooted at /root is "large" but none of its nodes has more
> than 100 direct child nodes. From what I could see, the amount of memory
> needed to execute the query grows aprox. linearly with the number of
> nodes in the sub tree.
>
> Is that expected? I was under the impression that query results would be
> collected lazily. Does that sound a bell for anyone?
>
> Any pointers to changes in the query engine which could have something
> to do with this are appreciated.
>
> Michael
>
>