[
https://issues.apache.org/jira/browse/SLING-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Sanso updated SLING-4891:
---------------------------------
Attachment: SLING-4891-patch3.txt
added new patch containing an OOM possible guard
{code}
private static final boolean DEFAULT_MAX_CACHED_VANITY_PATHS_STARTUP =
false;
@Property(boolValue = DEFAULT_MAX_CACHED_VANITY_PATHS_STARTUP,
label = "Limit the maximum number of cached vanity path entries
only at startup",
description = "Limit the maximum number of cached vanity path
entries only at startup" +
"Default is false")
private static final String PROP_MAX_CACHED_VANITY_PATHS_STARTUP =
"resource.resolver.vanitypath.maxEntries.startup";
{code}
> 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, SLING-4891-patch2.txt,
> SLING-4891-patch3.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)
