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

["Nitin Gupta (Jira)" <ji...@apache.org>]

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

Nitin Gupta commented on SLING-10447:
-------------------------------------

[~rombert]  [~Henry Kuijpers]  - I came across this Jira while investigating an issue with vanity paths query at startup. I see that the fix here is to add a NOT isDescendent clause in the query.

I think this would not help with avoiding the query hit limit. Because NOT isDescendent would not be fetched directly from index - so if it the NOT condition here even works - it would be done in memory by QueryEngine - which would mean the same amount of nodes would be read from the index as before.

 

[~thomasm]  - Please correct me if I am wrong here. 

> 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
>            Assignee: Robert Munteanu
>            Priority: Major
>             Fix For: Resource Resolver 1.8.0
>
>         Attachments: with-path-restrictions.json, without-path-restrictions.json
>
>          Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> 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.20.1#820001)