[
https://issues.apache.org/jira/browse/SLING-11439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17580357#comment-17580357
]
Thomas Mueller commented on SLING-11439:
----------------------------------------
[~reschke] hm... now that I think about it again... if processing the same
entry multiple times is not a problem, then I think the sorting by jcr:path is
not needed. Also, you don't need to count the entries.
I'm sorry I kind of blindly copied the query from here
https://jackrabbit.apache.org/oak/docs/query/query-engine.html#keyset-pagination
but didn't think that this here doesn't apply: "If your application requires
that the same node is only processed once, then additional logic is required to
skip over the entries already seen (for the same xyz)."
In your case, you can start with the last sling:vanityPath already processed,
and don't need to skip over any entries, as adding them again to the Bloom
filter is not an issue.
If you need an accurate count of entries, then some additional logic is needed,
but even that doesn't need order by jcr:path.
> resource resolver: fails to detect aborted vanity path query
> ------------------------------------------------------------
>
> Key: SLING-11439
> URL: https://issues.apache.org/jira/browse/SLING-11439
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
> Reporter: Julian Reschke
> Priority: Major
>
> With the introduction of the Oak query limit, JCR queries may get aborted
> when the result set size exceeds a certain value (currently by default
> 100000).
> However:
> https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/604332e9be17378276685033bdbce54994dad8c1/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceIterator.java#L115-L134
> So Apache Sling JCR Resource's API hides that exception, and thus resource
> resolver will happily startup with an incomplete cache.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
