[
https://issues.apache.org/jira/browse/SLING-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628828#comment-14628828
]
Alexander Klimetschek edited comment on SLING-4216 at 7/15/15 10:08 PM:
------------------------------------------------------------------------
[~cziegeler]: {quote} the "cache" contains only a fraction of the paths and
therefore a fallback to the repository (with a search?) sounds expensive and
might happen a lot{quote}
FWIW, That's what we are seeing in one case (SLING-4882 is related), with a
bloom filter size of 1000 and a large repo with 25K vanity paths. The queries
done on bloom filter misses take 1 to 2 seconds each and run on almost every or
at least many requests, and their result seems to be never cached.
It seems weird to me to have a cache for something that can be dynamic and
where you naturally want a LRU type caching, but the cache (the bloom filter)
is only generated on restarts.
was (Author: alexander.klimetschek):
[~cziegeler]: {quote} the "cache" contains only a fraction of the paths and
therefore a fallback to the repository (with a search?) sounds expensive and
might happen a lot{quote}
FWIW, That's what we are seeing in one case, with a bloom filter size of 1000
and a large repo with 25K vanity paths. The queries done on bloom filter misses
take 1 to 2 seconds each and run on almost every or at least many requests, and
their result seems to be never cached.
It seems weird to me to have a cache for something that can be dynamic and
where you naturally want a LRU type caching, but the cache (the bloom filter)
is only generated on restarts.
> Limit the number of vanityPath MapEntry
> ----------------------------------------
>
> Key: SLING-4216
> URL: https://issues.apache.org/jira/browse/SLING-4216
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Reporter: Antonio Sanso
> Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.1.10
>
> Attachments: SLING-4216-patch.txt, SLING-4216-patch.txt,
> SLING-4216-patch.txt
>
>
> At the moment there isn't any limit to the number of MapEntry that are cached
> in memory.
> If the number of vanityPaths/alias is extremely high this can cause OOM.
> It would be good to have a way to limit the amount of memory used by the
> MapEntry cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
