[
https://issues.apache.org/jira/browse/SLING-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355727#comment-17355727
]
Robert Munteanu commented on SLING-10447:
-----------------------------------------
[~kwin] - that actually looks scary to me :-) In case someone actually wants to
look in jcr:system for vanity paths for _whatever_ reason they will not be
found. Looking in the query docs I see noted that
{quote}Use excludedPaths, includedPaths with caution - When paths are excluded
or included then query engine is not aware of that. If wrong paths get excluded
then its possible that nodes which should have been part of query result get
excluded as they are not indexed. So only exclude those paths which do not have
node matching given nodeType or nodes which are known to be not part of any
query result{quote}.
I don't think we should recommend this kind of exclusion and should instead
make better queries.
> 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)
