The stat file in my cache root is not getting updated with activation requests; therefore old pages are getting served from dispatcher. The time-stamp is not getting modified. I read a post somewhere that the osgi configuration jcr observation listener might be stuck; and restarting it might cause the stat file's timestamp to update. If anybody knows how can we restart that particular osgi bundle; it will help a lot .Thanks
Solved! Go to Solution.
Views
Replies
Total Likes
Where is your dispatcher invalidation agent? Author or Publish?
What output are you getting in your dispatcher log when you activate a page that is not getting updated?
Does the repository path to the file match the cache path?
i.e. Is the content path in AEM "/content/mysite/page1" the same as the cache path, or are you removing "content" to give: /mysite/page1
Views
Replies
Total Likes
Hi,
What is your stat file level?
Regards,
Opkar
Views
Replies
Total Likes
Hi Opkar,
The statsfilelevel is commented; hence; the .stat file is getting formed in the cache root. The problem is that the time stamp is not getting updated for the .stat file.
Strangely; some pages are getting invalidated; and are getting refreshed when they are requested; but some are getting served the old version. I noticed that the time-stamp displayed on the stat file is of last may; while it shoudl be updated with each activation; right?
Thanks
Views
Replies
Total Likes
Hi,
can you test with /statfileslevel "0" just un-comment it
Regards,
Opkar
Views
Replies
Total Likes
Hi Opkar,
Thanks for your reply.
Since many pages are getting refreshed after activating; hence; statsfilelevel might not be the issue here. Also; its working without setting the statsfilelevel in other environments as well. Can you please let me know if I can check any other configuration ; which might be the issue behind this stat file not getting updated?
Thanks
Views
Replies
Total Likes
Can you check the owner, group and permissions on the root stat file, and compare those permissions with a stat file that is getting udated?
It could be that the user originally used to start the web server and hence create the stat file had different privileges(often this is root). Then at a later date a dedicated user was created to start the web server, who now doesn't have permissions to modify the stat file.
Regards,
Opkar
Views
Replies
Total Likes
Hi Opkar,
The the user which started the webserver is the same and it did not change and the user has permissions to modify the stat file. I also restarted the
com.day.cq.cq-replication
org.apache.sling.event and org.apache.felix.eventadmin bundles. Still it does not change. Really not sure why the file is not getting updated; also; some pages are getting refreshed and getting served properly.
Thanks
Views
Replies
Total Likes
Where is your dispatcher invalidation agent? Author or Publish?
What output are you getting in your dispatcher log when you activate a page that is not getting updated?
Does the repository path to the file match the cache path?
i.e. Is the content path in AEM "/content/mysite/page1" the same as the cache path, or are you removing "content" to give: /mysite/page1
Views
Replies
Total Likes
Hi Opkar,
Just checked that none of the pages are getting updated. The page which I mentioned as getting updated previously was actually created for the first time in cache.
So; none of the page is getting refreshed. and the .stat file is not getting updated with activation request.
The dispatcher invalidation agent is at publish
The repository path to the file does match the cache path; we have removed "/content" using the apache resourceresolver osgi config.
The error.log when a page gets activated is :-
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush Sending message to dispatcher-local:-1
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush >> GET /dispatcher/invalidate.cache HTTP/1.0
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush >> CQ-Action: Activate
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush >> CQ-Handle: /content/a/b/c/d/e/f/g/0032000001ICvZ1AAL
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush >> CQ-Path: /content/a/b/c/d/e/f/g/0032000001ICvZ1AAL
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush >> Referer: about:blank
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush >> Content-Length: 0
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush >> Content-Type: application/octet-stream
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush --
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush << HTTP/1.1 200 OK
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush << Date: Fri, 19 Jun 2015 11:57:00 GMT
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush << Server: Apache/2.2.15 (Red Hat)
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush << X-dynaTrace-JS-Agent: true
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush << Access-Control-Allow-Origin: *
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush << Vary: User-Agent
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush << Access-Control-Allow-Credentials: true
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush << Content-Length: 13
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush << Connection: close
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush << Content-Type: text/html; charset=UTF-8
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush <<
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush <<
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush Message sent.
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush ------------------------------------------------
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush Replication (ACTIVATE) of /content/a/b/c/d/e/f/g/0032000001ICvZ1AAL.
19.06.2015 12:57:00.533 *INFO* [pool-20-thread-28-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush)] com.day.cq.replication.Agent.flush.queue Job for agent flush processed in 3ms. Ok.
The dispatcher logs are
[Fri Jun 19 13:01:13 2015] [D] [1264(140318297421792)] checking [/dispatcher/invalidate.cache]
[Fri Jun 19 13:01:13 2015] [I] [1264(140318297421792)] Activation detected: action=Activate [/content/a/b/c/d/e/f/g/0032000001ICvZ1AAL]
[Fri Jun 19 13:01:13 2015] [D] [1264(140318297421792)] response.headers[Server] = "Communique/2.6.3 (build 5221)"
[Fri Jun 19 13:01:13 2015] [D] [1264(140318297421792)] cache flushed
[Fri Jun 19 13:01:13 2015] [I] [1264(140318297421792)] "GET /dispatcher/invalidate.cache" 0 13 1ms
I have provided 777 permissions to the .stat file. The dispatcher flush agent is working fine on publish; the test connection succeeded.
What else configurations can I check for making the .stat file to get updated
Thanks
Views
Replies
Total Likes
Are you adding in /content with a rewrite rule with mod rewrite?
What happens if you delete the .stat fuile, is it recreated?
Views
Replies
Total Likes
No we are not adding '/content' with mod_rewrite.
I deleted the .stat file but it did not get created with a new activation. So the problem is with the dispatcher module itself.
Views
Replies
Total Likes
Resource resolver will handle out going and incoming resolution at the aem level, if you use dispatcher you also need to consider what happens at the we server. Please check the article below to see how you handle dispatcher when using resource resolver
http://www.wemblog.com/2012/07/how-to-use-dispatcher-with-mapped.html?m=1
Views
Replies
Total Likes