[ https://issues.apache.org/jira/browse/SLING-11439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17564259#comment-17564259 ]
Thomas Mueller commented on SLING-11439: ---------------------------------------- A good page size for this use case would be 1000. 10'000 would work as well, but I doubt that it would be any faster (you can try). > Do we have any real-world example of code using this feature yet? Internally, inside Oak, we use variable page sizes for Lucene indexes (since many years now). First we load 50 (LUCENE_QUERY_BATCH_SIZE), then twice that much, up to some limit. But the use case is a bit different: we don't know how many we really need, so we start with 50. Your use case is: you always need all entries. So starting with a batch size of 50 and then increasing is not needed. > 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)