Hi there,
I have a Replication Event Listener that is running on AEMaaCS publisher. 1 week ago it worked fine, it received replication events as expected. Today I noticed that it stopped receiving replication events from the author when I publish any page. However, it still receives replication events that are triggered by org.apache.sling.sitemap.impl.SitemapScheduler on the publisher.
Below you can find my service declaration:
@component(
service = EventHandler.class,
property = {
"event.topics=com/day/cq/replication"
},
configurationPolicy = ConfigurationPolicy.REQUIRE,
immediate = true
)
Does anyone face this issue too? Does it make sense to reimplement EventHandler on com.day.cq.replication.Preprocessor?
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
I tried to re-implement according to ACS Commons Dispatcher Flush Rules implementation for cloud.
They build their logic on author environment by listening of org/apache/sling/distribution/agent/package/distributed.
However, I realized that can't properly handle such events on author instance. I have a logic to handle replicated paths with /etc/map and resource.resolver.mapping on publisher and I don't want to apply these mappings on author instance as well.
I modified my event listener and now it's listening com/adobe/granite/replication instead of com/day/cq/replication. This setup works for me as well.
Besides of that, I am sure that initial implementation worked as expected, but event handler was black-listed by reaching 5s timeout.
AFAIK the example you shared will catch the replication event on Author, not on Publisher. I can confirm this approach is working fine on my project. Also, you should not re-implement this with com.day.cq.replication.Preprocessor as that API is not supported on AEMaaCS.
Good luck,
Daniel
Hi @daniel-strmecki,
I tested this listener on publisher on local env and on AEMaaCS. It worked fine.
I am running this listener on publisher in purpose.
I know an alternative variant for listening of replication changes - listen org/apache/sling/api/resource/Resource/ADDED and org/apache/sling/api/resource/Resource/CHANGED. Is it a good alternative?
how are you running it on Publisher? Can you explain?
Catching replication events on Publisher in AEMaaCS is more tricky compared to On-Prem, as there are multiple publisher PODs and you usually want to catch the event and process it only once. Therefore, you can use the DiscoveryService to process it only on the leader POD.
Replication is done via Sling Distribution on AEMaaCS. I think this example from ACS Commons may be good to take a look: https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle-cloud/src/main/java/...
Hope it helps,
Daniel
Hi @daniel-strmecki ,
Nothing special. Just simple steps to start OSGi component on publisher.
1. Created OSGi service:
@Component(
service = EventHandler.class,
property = {
"event.topics=com/day/cq/replication"
},
configurationPolicy = ConfigurationPolicy.REQUIRE,
immediate = true
)
@Designate(ocd = MyReplicationEventListener.Configuration.class)
public class MyReplicationEventListener implements EventHandler {
2. Created OSGi configuration and put in under config.publish to start this component only on publisher.
Of course, I has this condition in this listener to handle event only on leader POD:
if (!discoveryService.getTopology().getLocalInstance().isLeader()) {
log.info("Skipping event {} because it's not a leader.", event);
return;
}
According to the logs, it caught replication events on AEMaaCS publisher.
Thank you for the code example. I was looking for it. I read that recently they have fixed Flush Rules for the AEMaaCS. I am going to try this approach.
I tried to re-implement according to ACS Commons Dispatcher Flush Rules implementation for cloud.
They build their logic on author environment by listening of org/apache/sling/distribution/agent/package/distributed.
However, I realized that can't properly handle such events on author instance. I have a logic to handle replicated paths with /etc/map and resource.resolver.mapping on publisher and I don't want to apply these mappings on author instance as well.
I modified my event listener and now it's listening com/adobe/granite/replication instead of com/day/cq/replication. This setup works for me as well.
Besides of that, I am sure that initial implementation worked as expected, but event handler was black-listed by reaching 5s timeout.
Do you have any reference documents that discuss the deprecation of the com.day.cq.replication.Preprocessor API in AEM as a Cloud Service? We currently have this API enabled in the Cloud(Author), and it is functioning correctly. Additionally, the Java packages show the API in the Developer Console. I’m curious to learn more details about its status and any related changes.
Regards
Albin I
https://myprofile.albinsblog.com
The most obvious reason for such an event handler to stop it got blocked because it took too much time. The OSGI implementation blocks event handlers which consume 5s of execution time per invocation. That means if you need to more complex operations or even external calls, you should delegate that work to a dedicated threadpool.
Hi @Jörg_Hoh , thank you for this assumption. After additional investigation I think that it's most obvious reason.
Actually, I know about 5s limitation for an event handler and always follow the best practice - to catch event and start Sling Job.
In this event handler I do the following:
All of these steps have to be fast.
As @Jörg_Hoh mentioned, this issue occurs when your event handler takes more time and gets blacklisted
To resolve this issue, You can configure your Event Handler to ignore timeout using IgnoreTimeout property in org.apache.felix.eventadmin.impl.EventAdmin OSGI configuration or else prefer using sling jobs
Hi @AMANATH_ULLAH , thank you for your suggestion. If I face it again, I will definitely white-list my event handler for the event admin.
Views
Like
Replies