[
https://issues.apache.org/jira/browse/SLING-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17356296#comment-17356296
]
Henry Kuijpers commented on SLING-10447:
----------------------------------------
[~kwin] I think, especially given that most of the vanity path
white-/blacklisting is configured in OSGi, that it's hard to keep indexes in
sync with these configs.
Also note that, (at least in AEM) the ntBaseLucene index already evaluates path
restrictions.
I'll use our bloated-with-versions-production-instance in a few to run some
querys, to see what the performance impact would be.
Also note that there are more paths to restrict. It's not only an exclusion for
/jcr:system that needs to be added, also:
* Includes for all paths mentioned in `resource.resolver.vanitypath.whitelist`
(and by design, if it is empty, an include for `/` instead)
* Excludes for all paths mentioned in `resource.resolver.vanitypath.blacklist`
(This is also visible in the PR.)
> 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
>
> Time Spent: 1h 10m
> 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)
