Apache Sling Resource alias caching?

[Jdruwe]

We are having the following issue (AEM 6.1):

1) Page A exists with alias: 'playground'

2) We've opened this page through our dispatcher using the alias 'playground' > everything works as expected

3) We remove Page A

4) Create a new Page B with the same alias: 'playground' on the same location Page A was

5) When we open the page (B) through the dispatcher using the alias 'playground' we get a 404 not found.

Why does this happen, is there some sort of alias cache? Can we flush a single record? Are we the only one experiencing this problem?

A solution that we found is to just resart the 'Apache Sling Resource Resolverorg.apache.sling.resourceresolver' bundle but we don't want do that on our production publishers obviously.

[Feike_Visser1 · Accepted solution]

Looks like a bug to me, did you raise a support ticket for this?

[Feike_Visser1]

Can you try one thing, disable "Optimize alias resolution", this is in the OSGi-config of the Resource Resolver Factory.

See screenshot.

[Jdruwe]

Feike Visser wrote...

Can you try one thing, disable "Optimize alias resolution", this is in the OSGi-config of the Resource Resolver Factory.

See screenshot.

I will try this on our ACC env and see how much of an impact it has. Would be useful if it was possible to remove a single 'alias-record' from the cache.

[ompandey]

Disabling the optimize alias resolution property works. But I read in one of the AEM blogs that this should almost always be left enabled[1].

Also, as per the field description, If we disable this, this might have an impact on the startup time and on the alias update time if the number of aliases is huge (over 10000). In our case it will be more than 10K pages. Is there a solution for this ? A solution like an option to clear the alias cache manually ?

[1]http://www.aemmastery.com/2015/03/15/aem-osgi-service-dive-resource-resolver-factory/

Optimize alias resolution: Creates an internal cache of aliases, meaning that if a mapping is successful that result is cached to avoid as much computation in the future.  But building the cache and updating it can also get expensive over time – but that’s extremely rare.  This should almost always be left enabled.