[
https://issues.apache.org/jira/browse/SLING-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14237896#comment-14237896
]
Carsten Ziegeler commented on SLING-4216:
-----------------------------------------
I haven't fully thought this through, but I would assume that if the number of
vanity paths is that high, 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. Assuming that most of the paths are accessed frequently
a LRU might not even help.
Right now we have one large data structure in memory, so what about fragmenting
this data structure and put parts of it somewhere else e.g. the file systems -
so everything stays as is, but we just don't keep the full structure in memory
(if it exceeds the limit)?
> 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
>
> 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)
