Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

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

aem-enthusiast
Level 2
Level 2

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);

}

}

}

1 Accepted Solution
Jörg_Hoh
Correct answer by
Employee
Employee

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).

 

View solution in original post

0 Replies
shaileshb584084
Level 3
Level 3

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

 

aem-enthusiast
Level 2
Level 2
Thanks, but we have to use event listener only. It's a business decision not to use workflows in this scenario.
shaileshb584084
Level 3
Level 3

In that case either you can use the jobs and process then serially, if you want it to be processed one by one.

Jörg_Hoh
Correct answer by
Employee
Employee

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).

 

View solution in original post

aem-enthusiast
Level 2
Level 2

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.

Jörg_Hoh
Employee
Employee

Hi,

 

ObservationListeners run asynchronous to the operation which performs the save. Which means that there is no guarantee at all regarding timing. So using the JCR Observation Handler to trigger another asynchronous operation (sling Job, or a custom implementation) does not make the situation worse. 🙂