[
https://issues.apache.org/jira/browse/SLING-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14633627#comment-14633627
]
Chetan Mehrotra commented on SLING-4891:
----------------------------------------
{noformat}
+ private void doAddVanity(Resource resource) {
+ // fill up the cache and the bloom filter
+ loadVanityPath(resource, resolveMapsMap, vanityTargets, true
/*addToCache*/, true /*newVanity*/);
+ vanityCounter.incrementAndGet();
updateBloomFilterFile = true;
}
{noformat}
With new change any cache miss would lead to updateBloomFilterFile set to true.
Which is technically not required as the vanityPath might already be recorded
in bloom filter so update of bloom filter would not be required. Though looking
at impl it would not add much to performance cost but still something to
consider
> Improve MapEntries to cache searched vanity paths
> --------------------------------------------------
>
> Key: SLING-4891
> URL: https://issues.apache.org/jira/browse/SLING-4891
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Reporter: Antonio Sanso
> Assignee: Antonio Sanso
> Attachments: SLING-4891-patch.txt
>
>
> At the moment {{PROP_MAX_CACHED_VANITY_PATHS}} limits the number of in memory
> cached vanity paths in order to have a faster startup.
> I'd propose to slightly change the semantic of the limit of the cache .
> We can indeed limit the cache only for startup and when a vanity path query
> is executed and results are returned those can be added to the cache (and not
> thrown away as is now).
> If this same entry will be again requested it will be delivered from the
> cache, so fast.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
