[
https://issues.apache.org/jira/browse/SLING-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17356348#comment-17356348
]
Henry Kuijpers commented on SLING-10447:
----------------------------------------
I just attached 2 files, one with a query with path restrictions (as they would
be generated when the mentioned PR is merged) and one without path restrictions
(as it works now).
The instance has ~5000 vanity paths in the /content-node and a few in /libs
(and maybe some in /apps) of course. There are roughly 120.000 vanity paths
under the /jcr:system node (they reside in the /jcr:system/jcr:versionStorage
node).
I see no alerting impact of the query with the path restrictions over the query
without. In fact, I see that it seems to perform better, in terms of node
traversal, which of course makes sense.
> 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
>
> Attachments: with-path-restrictions.json,
> without-path-restrictions.json
>
> Time Spent: 1h 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.3.4#803005)
