Dear Members,
I am facing one different kind of issue,
After clearing the dispatcher cache multiple times, still query parameter is required to show the actual content from the publisher in incognito of the chrome browser\\.
Some more point:
1.There is some anomaly in the author and publisher content.
2.I am using SDI to cache the experience fragment component on the page.
3.Experience fragment is being used for header and footer.
can anyone has faced such an issue ? Please suggest what should be done to get rid-off from this issue.
Thanks
Umesh Thakur
Solved! Go to Solution.
Views
Replies
Total Likes
It was resolved.
Issue was with the SDI, that we use for XF caching, when SDI was enable it was adding one CSS file in the page source for XF component so this CSS file was altering the page's look and fill but when I was using query parameter, it was skipping the SDI as well as dispatcher so getting the actual content as it was there on the publisher server.
Thanks all for your suggestions on this topic.
Is it issue only with chrome browser ? Did you try chrome without query param and incognito ?
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
First thing I would check is if your invalidation is happening properly - once you publish the page, open it up and see if you have a new version of the file created on the hard drive on Apache
Once you confirm that a new file is getting created I would then check if the calls hit your server - there might be another caching layer in front of it, e.g.:
1. CDN / Varnish - I assume you would know about this one?
2. Proxy - sometimes in corporates there are proxies which might hold something for a while - there are headers which can instruct proxies not to cache certain things
3. Browser cache - you should be able to see in the browser's Dev Tools -> network tab if the call is actually flying to the server
* Do you have any CDN on top of your AEM tier? If yes, try to reproduce the issue by bypassing the CDN.
* If you aren't using any CDN:
a) Are you clearing the cache manually, or are you using the dispatcher flush agent to flush the cache when content is published? If you are using dispatcher flush agent, verify whether the dispatcher flush queue isn't stuck.
If clearing the cache manually, enable DEBUG logging on dispatcher, restart the apache server, clear all cache, and then try to reproduce the issue. Do a tail of the dispatcher log file, and then try to access that page, and see how the request is being served, in the dispatcher log file.
b) If you have an XF that you clear the cache for, but use the same XF on multiple pages, if you publish the XF, the flush will clear the cache of that XF only. It won't clear that XF cached on the pages on which it's being used. They need to be flushed/cleared separately. For that you can write a custom script, that gets triggered when you the XF is published, such that it clears the cache of the pages on which the XF is being used. This way, it will serve the fresh content.
Hope it helps !!
It was resolved.
Issue was with the SDI, that we use for XF caching, when SDI was enable it was adding one CSS file in the page source for XF component so this CSS file was altering the page's look and fill but when I was using query parameter, it was skipping the SDI as well as dispatcher so getting the actual content as it was there on the publisher server.
Thanks all for your suggestions on this topic.