[ https://issues.apache.org/jira/browse/SLING-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355697#comment-17355697 ]
Konrad Windszus commented on SLING-10447: ----------------------------------------- Look at https://jackrabbit.apache.org/oak/docs/query/lucene.html#include-exclude bq. Note that excludedPaths and includedPaths does not affect the index selection logic for a query i.e. if a query has any path restriction specified then that would not be checked against the excludedPaths and includedPaths. So the answer to your question is yes. > sling:vanityPath are being searched during startup in the entire repository, > including version storage > ------------------------------------------------------------------------------------------------------ > > Key: SLING-10447 > URL: https://issues.apache.org/jira/browse/SLING-10447 > Project: Sling > Issue Type: Bug > Components: ResourceResolver > Affects Versions: Resource Resolver 1.7.6 > Reporter: Henry Kuijpers > Priority: Major > Fix For: Resource Resolver 1.7.8 > > > We have a lot of pages on our production author instance. We also have a lot > of pages that use sling:vanityPath. Everytime a page is replicated, a new > version is created. > We have roughly 168.000 pages in our instance. In the /content node, there > are approx. 4500 pages with vanity URLs. In the version storage, however, > there are 120.000+ entries that have a sling:vanityPath defined. > When starting up Apache Sling, the Resource Resolver fetches all the existing > sling:vanityPath entries, which it fails to do, because of the large amount > of sling:vanityPath in the version storage. > In the code, I specifically see checks (when processing the query results) > about the version storage. However, this should have been put inside the > query as a filter, in order to avoid fetching such a large amount of query > result nodes: > https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/4406b8fed0fedb48202fc6472fb552c36aa06e35/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L1158 > I propose to update the query with a "not isdescendantnode"-check, to make > sure we do not return any content from the version storage and thus make the > default query limits of 100.000 nodes work again. -- This message was sent by Atlassian Jira (v8.3.4#803005)