Expand my Community achievements bar.

SOLVED

AEM as a Cloud local dispatcher does not have statfile

Avatar

Level 2

I have Dispatcher running locally, and there does not appear to be any statfile in the cache.

I have the statfilelevel "2"

I have published a page, fetched it through the dispacther, then updated the content on Author and published again.

The Dispatcher Flush agent is running on the Author and the logs show successful replication and invalidate.

Looking at the Dispatcher logs I see the message "never flushed".

 

the http://localhost:8080/dispatcher/invalidate.cache ruturns "It Worked", but the files remain.

 

Am I missing something here?

1 Accepted Solution

Avatar

Correct answer by
Level 2

It appears the dispatcher which comes from the AEM Cloud SDK contains many immutable files, even though you give a path to your local dispatcher source.  So even though you change values locally, they are never taken into consideration.

For instance: default_invalidate.any cannot be changed to allow 127.0.0.1 to invalidate the cache, therefore on page activation the cache is never flushed.

My solution was to setup the Dispatcher on my Mac and change the dispatcher configurations, which produced the .stat files corrected.

Also, to run /dispatcher/invalidate.cache I discovered that it should be performed using Postman since the Headers CQ-Action, CQ-Handle and Content-Length need to be passed to the call.

View solution in original post

8 Replies

Avatar

Community Advisor

i believe with invalidate its just invalidate the files and won't delete it physically from the cache directory. the file will be get freshly cached once that files is requested again after the invalidate 

Avatar

Level 2

Thanks for your reply, but the missing statfile still makes me scratch my head.  

I have run dispatcher/invalidate.cache and then requested a file which serves the old file still in cache.

Avatar

Community Advisor

If you haven’t configured statfile property on dispatcher then by default it creates a .stat file and it’s creation depended on statfilelevel as well. So check on your windows if you can see the “.stat” file there

Avatar

Level 2

Here is from the log

00 /cache {
2023-05-01 08:46:00 /docroot "/mnt/var/www/html"
2023-05-01 08:46:00 /statfileslevel "2"
2023-05-01 08:46:00 /allowAuthorized "0"
2023-05-01 08:46:00 /serveStaleOnError "1"
2023-05-01 08:46:00 /rules {
2023-05-01 08:46:00 /0000 {
2023-05-01 08:46:00 /glob "*"
2023-05-01 08:46:00 /type "allow"

....

 

There is no stat file in html directory or content directory or subdirectory

 

/mnt/var/www/html # ls -lta
total 0
drwxr-xr-x 6 apache apache 192 Apr 28 19:24 content
drwxr-x--- 4 apache apache 128 Apr 28 19:24 .
drwxr-xr-x 6 apache apache 192 Apr 27 15:17 etc.clientlibs
drwxr-xr-x 3 root root 96 Apr 25 16:46 ..

Avatar

Community Advisor

At what level page did you published?

Avatar

Level 2

level 4

I think it is something with the AEMaaC dispatcher configuration and I can't change 

default_invalidate.any which contains ${AEM_IP} for the dispatcher invalidate

Avatar

Community Advisor

To test if .stat file is created or not can you increase the statfilelevel to 6 and publish the page at level 4

Avatar

Correct answer by
Level 2

It appears the dispatcher which comes from the AEM Cloud SDK contains many immutable files, even though you give a path to your local dispatcher source.  So even though you change values locally, they are never taken into consideration.

For instance: default_invalidate.any cannot be changed to allow 127.0.0.1 to invalidate the cache, therefore on page activation the cache is never flushed.

My solution was to setup the Dispatcher on my Mac and change the dispatcher configurations, which produced the .stat files corrected.

Also, to run /dispatcher/invalidate.cache I discovered that it should be performed using Postman since the Headers CQ-Action, CQ-Handle and Content-Length need to be passed to the call.