AEM 6.5 : How to make event listener not wait for an event to complete | Community
Skip to main content
Level 2
December 9, 2020
Solved

AEM 6.5 : How to make event listener not wait for an event to complete

  • December 9, 2020
  • 2 replies
  • 3646 views

Hi,

 

We have a requirement to listen on the node additions in a particular jcr path and do some processing on the added nodes by calling our custom java code whenever an event happens. The scenario is like, say a node is added in AEM, the listener listens on the event and calls custom java code to do further processing and until this processing is complete, the listener is waiting. So the listener completes one event and then moves on to the second. It's a while loop on the event iterator. 

We want that the listener should hand over the processing of event to custom java code and move on to the next event and not wait for the java code processing to be over.

We considered jobs but it using jobs was ruled out as we want the code processing to be in real time without any delay and that's why we want parallel processing.

How can we achieve that with an event listener? 

Thanks

 

Code snippet:

public void onEvent(EventIterator events) {

while(events.hasNext()) {

Event nextEvent = events.nextEvent();

try{

//custom java code called here

} catch (RepositoryException e) {

log.error("RepositoryException occurred", e);

}

}

}

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

From what I know this is not possible.

 

You would need to use multiple threads to handle the events of an event iterator in a parallel way. But the code on that low level is not thread-safe. But to be honest I have never tried that, and I am very sure, that you would be the first one to try that.

The rule of thumb for JCR Observation Listener is to be as fast as possible. If you processing is expected to take longer, you should offload from this thread (e.g. feeding a queue where a dedicated threadpool is picking the work from, or creating Sling Jobs, or ...). But of course then the processing gets asynchronous from the JCR Observation Listener (which are by the way asynchronous to the actual save() operation).

 

2 replies

Level 2
December 9, 2020

Hi,

 

The drawback for the even listener is that it gets called at all the events and then you have to filter the request based on your conditions.

 

It is advised to use the workflows using the launchers for this case. As you can restrict the event's based on various conditions and those conditions could be changed on the fly without any dependency on the deployment required.

 

If the number of workflows those are getting triggered are quite high in number and remain in active state. Then should think about the alternate solution.

 

Thanks

 

Level 2
December 9, 2020
Thanks, but we have to use event listener only. It's a business decision not to use workflows in this scenario.
joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
December 9, 2020

From what I know this is not possible.

 

You would need to use multiple threads to handle the events of an event iterator in a parallel way. But the code on that low level is not thread-safe. But to be honest I have never tried that, and I am very sure, that you would be the first one to try that.

The rule of thumb for JCR Observation Listener is to be as fast as possible. If you processing is expected to take longer, you should offload from this thread (e.g. feeding a queue where a dedicated threadpool is picking the work from, or creating Sling Jobs, or ...). But of course then the processing gets asynchronous from the JCR Observation Listener (which are by the way asynchronous to the actual save() operation).

 

Level 2
December 10, 2020

Thanks for the response.

Can you please elaborate a little on "which are by the way asynchronous to the actual save() operation." I didn't get that part. Also if you have any example of sling jobs executing from an event listener that would be great.

Thanks again. Regards.