DIspatcher Flush Issue - Stat file creation | Community
Skip to main content
EstebanBustamante
New Participant
May 12, 2023
Solved

DIspatcher Flush Issue - Stat file creation

  • May 12, 2023
  • 1 reply
  • 2014 views

Hi, 

 

I am seeing an odd behavior while flushing cache, I am using AEM 6.5.16 with the wknd site for testing, also I am using a dispatcher in a Centos machine and it was set using the default configs from the AEM Project archetype (v41).

 

So, the statfilelevel is set to 2 by default as shown below:

 /cache {
# The cacheroot must be equal to the document root of the webserver
/docroot "${PUBLISH_DOCROOT}"
# sets the level upto which files named ".stat" will be created in the
# document root of the webserver. when an activation request for some
# handle is received, only files within the same subtree are affected
# by the invalidation.
/statfileslevel "2"

According to this documentation https://experienceleague.adobe.com/docs/experience-manager-learn/ams/dispatcher/disp-flushing.html?lang=en#stat-files-level my expectation would be to have .stat 3 files when a flush event is triggered, like below:

 

- /var/www/html/.stat (statfilelevel 0) - /var/www/html/content/.stat (statfilelevel 1) - /var/www/html/content/wknd/.stat (statfilelevel 2)

 

 But actually, I see in the logs there are only 2 .stat files being created. These files are being touched correctly, if i re-flush the cache, those are being updated correctly (timestamp), so the cache "should" invalidate.

The problem is when I request again a page such as: [/content/wknd/us/en.html], the dispatcher is looking for a .stat file at a deeper level

[/mnt/var/www/html/content/wknd/.stat], which does not exist as explained above, and thus the cache is not invalidated.

 

So here are my questions:
1) Is really expected that only 2 .stat files should be created when the statfilelevel is set to 2? If not, how can I troubleshoot further? 

2) Even if the file .stat does not exist at the deeper level, was not supposed that the dispatcher should look up the nearest .stat file? Which I understand is the one located at [/content/.stat] level and thus invalidates the whole [/content/wkn] path.

 

Things that I've tried so far that gave the same result:

- I made sure the dispatcher config is correctly set and restarted the Apache server several times,

- I made sure the directories have the proper write access and I have disabled SELinux security just in case is messing with the folder.

- Flush via CURL command or via ACS Flush Feature, the same result, only 2 files are created

- Increased the statfilelevel to 3, the .stat files are still only 2, what changes is that the dispatcher will look for a .stat file in a deeper level to validate against the previous invalidation process e.g: [/mnt/var/www/html/content/wknd/us/.stat]

 

 

Hope someone can provide some hints to understand what's going on. 

 

Thanks in advance

 

 

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by EstebanBustamante

@estebanbustamante , were you able to sort this up? If so, I would request you to share the solution with AEM community for posterity. 


Yes, in case someone else is misunderstanding this.

What I miss here was the fact that there is a difference between DELETE and ACTIVATE replication action types. It looks like the .stat files are relevant when using ACTIVATE type because this is targeted for a single resource, in the other case, if I need to flush a whole directory I would use DELETE and won't care about the stats files.

 

Here is more info about it:

https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-rules/index.html

 

 

1 reply

rawvarun
New Participant
May 17, 2023
EstebanBustamante
New Participant
May 17, 2023

Did you fully read the question? I provided screenshots showing the logs which of course are at debug level.

Esteban Bustamante
rawvarun
New Participant
May 17, 2023

Are you using AMS or AEM as a cloud?

I see the AMS documentation link for the dispatcher mentioned in your question.