[jira] [Commented] (SLING-4216) Limit the number of vanityPath MapEntry

["Alexander Klimetschek (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628828#comment-14628828 ] 

Alexander Klimetschek commented on SLING-4216:
----------------------------------------------

[~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)