Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Unable to flush dispatcher cache on publish

Avatar

Level 9

Hi,

 

Anyone knows how this issue can be resolved? We have a dispatcher flush configured on pub prod but the cache invalidation does not appear to be done 

Reason i say it is dispatcher and not cloudfront , is , ?a=b invalidates it. Unless I am  missing something? Anyone knows how i could get past this?

1 Accepted Solution

Avatar

Correct answer by
Level 9

Thanks both of you @Shiv_Prakash_Patel @SantoshSai 

 

I happened to notice that acs dispatcher ttl was set on pub config run mode and was being picked up so that explained the duration that the origin was picking up but it ended up being cloudfront that was not invalidating due to config.

 

Much appreciated guys!

View solution in original post

4 Replies

Avatar

Level 9

Anyone please? Do we think setting statfileslevel from 1 to 17 would help? or should i set it to doc root 0?

Avatar

Community Advisor

Hi @NitroHazeDev ,

  • Publication and cache invalidation take place at the same time. Depending on the timing a user may request a page just after it was removed from the cache and just before the new page is published. AEM now returns the old page and the Dispatcher caches it again. This is more of an issue for large sites.
  • Hitting by queryString param will not clear cache but serves the content from publisher.

For more details to check what is missing please check these article having 4 steps to get it done: https://sourcedcode.com/blog/aem/how-to-setup-the-aem-dispatcher-flush-agent

Additionally, you can invalidate the dispatcher cache manually: https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/page-invalid....

 

Question about about your /statfileslevel It depends on your project structure please check Invalidating Files by Folder Level how it works: https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/dispatcher-c... 

  • When a file located at a certain level is invalidated then all .stat files from the docroot to the level of the invalidated file or the configured statsfilevel (whichever is smaller) will be touched.

    • For example: if you set the statfileslevel property to 6 and a file is invalidated at level 5 then every .stat file from docroot to 5 will be touched. Continuing with this example, if a file is invalidated at level 7 then every . stat file from docroot to 6 will be touched (since /statfileslevel = "6").

Only resources along the path to the invalidated file are affected. Consider the following example: a website uses the structure /content/myWebsite/xx/. If you set statfileslevel as 3, a .statfile is created as follows:

  • docroot
  • /content
  • /content/myWebsite
  • /content/myWebsite/*xx*

When a file in /content/myWebsite/xx is invalidated then every .stat file from docroot down to /content/myWebsite/xxis touched. This would be the case only for /content/myWebsite/xx and not for example /content/myWebsite/yy or /content/anotherWebSite. 

 

Hope that helps!

Regards,

Santosh

Avatar

Level 4

Hi @NitroHazeDev ,

For Dispatcher flush agent setting, Please check the article suggested by @SantoshSai .

/statfileslevel is used to selectively invalidate cached files according to their path. statfilelevel is 0 for docroot folder. you can set it as per your requirement. (Section - Invalidating Files by Folder Levelhttps://aemcq5pedia.wordpress.com/2018/01/18/aem-dispatcher/ ).

For automatic invalidation configuration please check (Section - Automatically Invalidating Cached Files - https://aemcq5pedia.wordpress.com/2018/01/18/aem-dispatcher/ ).

Hope this could help you!!!

Thanks

Shiv

 

Avatar

Correct answer by
Level 9

Thanks both of you @Shiv_Prakash_Patel @SantoshSai 

 

I happened to notice that acs dispatcher ttl was set on pub config run mode and was being picked up so that explained the duration that the origin was picking up but it ended up being cloudfront that was not invalidating due to config.

 

Much appreciated guys!