Replication Event Listener stopped working on AEMaaCS Publisher

[konstantyn_diachenko]

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?

[daniel-strmecki]

Hi @konstantyn_diachenko,

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

[konstantyn_diachenko]

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?

[daniel-strmecki]

Hi @konstantyn_diachenko,

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

[konstantyn_diachenko]

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.

[konstantyn_diachenko · Accepted solution]

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. 

[AlbinIs1]

Hi @daniel-strmecki 

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

[daniel-strmecki]

Hi @AlbinIs1,

not really, for me, it didn't work when I tested it some time ago. If someone from Adobe can confirm that would be great.

[Jörg_Hoh]

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.

[konstantyn_diachenko]

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:

1. check that this event handler is running on leader POD
2. check that event paths are allowed
3. start Sling job

All of these steps have to be fast.

[AMANATH_ULLAH]

@konstantyn_diachenko 

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

[konstantyn_diachenko]

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.