[
https://issues.apache.org/jira/browse/SLING-11800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894850#comment-17894850
]
Julian Reschke edited comment on SLING-11800 at 6/6/25 12:25 PM:
-----------------------------------------------------------------
Summary of things to consider:
- We currently have two different code paths for alias resolution - the classic
deprecated one (always hitting the repo for lookup), and the optimized one
using a cache. -We either need to get rid of the deprecated one, or refactor
code so that they behave the same (see SLING-12025)- EDIT: done in SLING-12795
- For aliases, the memory cache is not limited; for vanity paths it is (size
configurable in OSGi); the latter works as we are populating a Bloom filter
when reading the vanity paths. This way, when we have a cache miss, we know
whether it may make sense to ask the repo. Having both caches behave
differently seems like a bad idea. Either memory is an issue or it's not.
- For aliases, the actual lookup from the repo is more expensive than for
vanity paths. For the latter, when we initialize the cache asynchronously, we
fall back to the "ask the repo" approach (with limited caching). The same
approach for aliases might be more expensive due to the more complex query.
was (Author: reschke):
Summary of things to consider:
- We currently have two different code paths for alias resolution - the classic
deprecated one (always hitting the repo for lookup), and the optimized one
using a cache. We either need to get rid of the deprecated one, or refactor
code so that they behave the same (see SLING-12025)
- For aliases, the memory cache is not limited; for vanity paths it is (size
configurable in OSGi); the latter works as we are populating a Bloom filter
when reading the vanity paths. This way, when we have a cache miss, we know
whether it may make sense to ask the repo. Having both caches behave
differently seems like a bad idea. Either memory is an issue or it's not.
- For aliases, the actual lookup from the repo is more expensive than for
vanity paths. For the latter, when we initialize the cache asynchronously, we
fall back to the "ask the repo" approach (with limited caching). The same
approach for aliases might be more expensive due to the more complex query.
> resource resolver: optionally run initial alias query asynchronously
> --------------------------------------------------------------------
>
> Key: SLING-11800
> URL: https://issues.apache.org/jira/browse/SLING-11800
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.8.6
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Major
>
> ...to avoid slow startup in presence of many alias resources.
> (add OSGi switch and keep the old behavior as default for now)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
