Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED
Vanity URLs Dispatcher Cache Invalidation - Adobe AEM/CQ
wrote...
I was trying to configure the dispatcher invalidation configuration as per Adobe Dispatcher Invalidation documentation. As per the documentation
Cache invalidation requests for a page are also generated for any aliases or vanity URLs that are configured in the page properties.
I created a vanity URL in page properties dialog. When I publish the page for which Vanity URL property is set, I can see the logs indisptacher.logchecking [/dispatcher/invalidate.cache] Activation detected: action=Activate [/content/geometrixx/en/products] Touched /app/server/aem-apache/htdocs/cache/.stat response.status = 200 response.headers[Server] = "Communique/2.6.3 (build 5221)" response.headers[Content-Type] = "text/html" cache flushed "GET /dispatcher/invalidate.cache" 200 13 0ms
But when i check the configured (inside dispatcher.any) docroot cache folder inside Apache web server. Only cache corresponding to full page path is cleared (e.g. /content/geometrixx/en/products in logs). But the vanity URL accessed file (e.g. /mySite/prodct.htm) is still there.
Do we need to do more configuration for invalidating the cache for Vanity URLs?
If AEM//Dispatcher worked as per the documentation above, and if you used Dispatcher 4.1.9, then Dispatcher would be aware of vanity url's(obtained from AEM) and these would get flushed on activation from publish/author. However, for the time being it seems you need to set a stat level of 0 in order to clear vanity urls cached.
wrote...
I tried setting the statlogfile level to 0. But still the dispatcher cache is not being cleared for vanity url..
Can someone please share some inputs on the vanityURL package that is available on package share? what is it for and how can this be used. it says that it enables the dispatcher to handle vanity urls automatically.
can someone share the link for ticket GRANITE-9224 as mentioned in one of the comments on this thread?
Thanks.
The package you mentioned is explained in [1]. The purpose of this is to make Dispatcher away of vanity URL's. In typical use cases you set up Dispatcher and allow specific paths through to AEM.
In a typical use case you have a specific pattern that the url starts this, you identify it as valid and pass it through to AEM. If you pattern is not found then the request is blocked. Because vanity urls can be anything, they break your patterns, so either you have to include all vanity url's in your rewrite rules or you let everything through to AEM(which is bad). So with the new feature, Dispatcher get's a list of all vanity URL's from AEM and stores them, so if the incoming url is blocked by the dispatcher rules, it will check the list of vanity url's to check if the request should be passed to AEM.
As far as your current issue is concerned, what happens when you clear the dispatcher cache, if you call your vanity URL is it recreated in your dispatcher cache?
Related Conversations
