[jira] [Comment Edited] (SLING-10447) sling:vanityPath are being searched during startup in the entire repository, including version storage

["Konrad Windszus (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355697#comment-17355697 ] 

Konrad Windszus edited comment on SLING-10447 at 6/2/21, 1:05 PM:
------------------------------------------------------------------

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 (given that the index with the path restriction is selected for the query based on its score)


was (Author: kwin):
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)