Hi there,
The issue:
Every time I publish a page, I don’t see the content updated at the publish-xxx-xxx URL (dispatcher).
Things I’ve tried to troubleshoot:
Disabled the CDN cache (Fastly) to ensure it's not cached there (didn’t work).
Disabled the "enableTTL" config in the dispatcher (didn’t work).
Set "/statfileslevel" to 0 (didn’t work).
Set "/invalidate" with "/0000 { /glob "*" /type "allow" }" (didn’t work).
Tested my dispatcher config using the local SDK dispatcher (flushing worked fine, although this uses the Replicator API).
Reset my dispatcher config to the original archetype version (still didn’t work).
Reviewed the Sling Distribution Queue — all looks good, the queue is not blocked.
Checked the Sling Distribution Queue logs — shows "type=ADD" is sent on each publication.
Dispatcher logs don’t show more than "[actionhit]" on the request.
I've updated the logs to debug level by setting the DISP_LOG_LEVEL variable to Debug (in the global.vars file), but I still see the "[I]" indicator in the logs. Is that expected?
Questions:
Is there a way to check if the .stat files are actually being created?
Is there anything I might be missing that could be preventing a normal "page publication" from flushing the dispatcher cache?
Any suggestions are welcome.
Solved! Go to Solution.
Views
Replies
Total Likes
Hi,
Make sure the "localhost" host is part of your vhost file, as the dispatcher flush request usually comes from the same pod where the dispatcher and publisher agent are located. If this is not present, most likely the flush requests are not being accepted/resolved by your dispatcher config.
Hope this helps
Hi @New_Noob ,
When content is updated, Dispatcher updates the timestamp of the stat file.
Files are invalidated by touching the .stat file. The .stat file’s last modification date is compared to the last modification date of a cached document. The document is re-fetched if the .stat file is newer.
You can also try to debug, as what happens in caching by adding the header X-Dispatcher-info to a request, Dispatcher answers whether the target was cached, returned from cached, or not cacheable at all. The response header X-Cache-Info
contains this information in a readable form. You can use these response headers to debug issues involving responses cached by the Dispatcher.
This functionality is not enabled by default, so for the response header X-Cache-Info
to be included, the farm must contain the following entry:
/info "1"
Also, the X-Dispatcher-info header does not need a value, but if you use curl
for testing, you must supply a value to send to the header, such as:
curl -v -H "X-Dispatcher-Info: true" https://localhost/content/wknd/us/en.html
You can find more details here:
https://experienceleague.adobe.com/en/docs/experience-manager-dispatcher/using/configuring/dispatche...
Also few more command that you can use , related to stat file:
To find stat file:
find /mnt/var/www/html/ -type f -name ".stat"
To find timestamp:
$ watch -n 3 "find /mnt/var/www/html/ -type f -name ".stat" | xargs ls -la $1"
Hope it helps!
-Tarun
Hi @TarunKumar thank you for the response, but as i said this is AEMaaCS, where you dont have access to the dispatcher server, so i cannot verify the .stat files. Also, the debugging header is not valid in AEMaaCS just on premise, so if you have any other suggestion it would be highly welcome
Views
Replies
Total Likes
Hi,
Make sure the "localhost" host is part of your vhost file, as the dispatcher flush request usually comes from the same pod where the dispatcher and publisher agent are located. If this is not present, most likely the flush requests are not being accepted/resolved by your dispatcher config.
Hope this helps
Views
Likes
Replies