One more thing I would like to mention is the performance of Publish Content Tree in publishing 100 thousand Content Fragments if sometimes we have to update all the Content Fragments is very poor. It seems to fail even if we divide into sub categories with range from 10 thousand to 20 thousand. Fr...
We have an overnight job that takes data from 3rd party source and updates tens of thousands of Content Fragments. Our job then runs OOTB Publish Content Tree Workflow to publish all the content fragments. These publishing workflow jobs take long time to run and many time die running for more than...
Turns out that CQ-Action: Test header sent to the invalidate.cache was just to test the connectivity as part of monitoring. I have confirmed by observing the dispatcher cache that these events do not clear the full dispatcher cache Thank you for your help @Jörg_Hoh @EstebanBustamante
Seen this New relic header: in the test call below:X-NewRelic-App-Data: PxQFVFJbDQYBR1BSDgUGU1QJBgdASkE1VQBsEFlWR1NQEVAOXz0cMQhfWQY6TEpWUwEIFFITG1ZKARoDTFZTUAFVC1YLChgCH0cMBwZQCgAFAg4FVFMKUFJVQ05RUFsVAWw= Is it possible that NewRelic is sending test requests. I could not find any other monitoring se...
@Jörg_Hoh Adding screen shots of the replication agent on the publisher that does not work on the regular replication but on the replication events:And in the logs of this agent I see the invalidate.cache without the author activated pages though I see some author activated pages/exp fragments as w...
@Jörg_Hoh found around over a 100 entries in the dispatcher log matching this though our site is not edited heavily. It is usually a few dozen edits per day max but there are a lot of invalidate cache calls in dispatcher and the fact that these calls happen regularly i.e. many times in each hour: [T...
@Jörg_Hoh but it keeps on sending invalidate.cache requests. My fear is that it might be clearing the full cache 15.06.2023 18:38:12.854 *INFO* [[0:0:0:0:0:0:0:1] [1686854292851] GET /etc/replication/agents.publish/dispatcher2uswest1Agent.test.html HTTP/1.1] com.day.cq.replication.Agent.dispatcher2u...
We have been running into an issue where the publisher logs have a lot of invalidate cache request not related to the author page/assets publish. Any ideas why are we getting this? An example of such is pasted below. 15.06.2023 18:38:12.852 *INFO* [[0:0:0:0:0:0:0:1] [1686854292851] GET /etc/replicat...
The issue is resolved by following this page from acs commons documentation:
https://adobe-consulting-services.github.io/acs-aem-commons/pages/maven.html
I was missing the dependency below in the all project pom.xml:
<dependency>
<groupId>com.adobe.acs</groupId>
<artifactId>acs-aem-common...
We have been running into an issue where the publisher logs have a lot of invalidate cache request not related to the author page/assets publish. Any ideas why are we getting this? An example of such is pasted below. 15.06.2023 18:38:12.852 *INFO* [[0:0:0:0:0:0:0:1] [1686854292851] GET /etc/replicat...Perguntas
27/03/2024
