hi *, I have been working on [0], namely Limit the number of vanityPath MapEntry. In a nutshell at the moment we keep a cache of vanityPaths. So far so good. The problem is that this cache is unbounded. Namely if the Sling instance has 1000000 vanityPaths all the vanityPaths are kept in memory. Of course the memory is limited and is not hard to imagine an OutOfMemory… For this reason I am willing to propose a limit the number of vanity path Osgi configuration. That’s said we need now to adapt the map/resolve algorithm to this new situation. So far I so two possible solutions ( but IMHO one is really not a way to go). Let’s take in consideration the resolve case (the map case can be then solved in a similar way).
The two possible solution are when the cache is bound: - do a search for a vanityPath if the /requestPath is not in the cache (as anticipated above I think this is not a great solution since it can be expensive, indeed I assume the majorities of requests are not even “vanityPath requests” so both the cache and the search will return empty result) - the second solution is a bit more convoluted but way more efficient. Let me try to explain: * the cache is now bounded to the number of vanityPath entries as per config * the algorithm stays as is for now for resolve(). So it before looks for vanityPath in the cache and then continues to look in the repository for a path that matches a resource * if a requestedPath ends to be evaluated as NonExistingResource a last resort vanityPath search is executed and tries to find for a vanityPath entry There is only on problem here. This indeed can lead to a non compatible change and can work only if we also introduce a new configuration where a vanityPath cannot be set to a value that is equal to an existing resource. E.g. if I have some content /foo and in /bar I try to set a vanityPath /foo this is not taken in consideration as valid vanityPath Sorry for the rather complicated mail but WDYT? regards antonio [0] https://issues.apache.org/jira/browse/SLING-4216
