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);
}
}
}
Solved! Go to Solution.
Views
Replies
Total Likes
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).
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
Views
Replies
Total Likes
In that case either you can use the jobs and process then serially, if you want it to be processed one by one.
Views
Replies
Total Likes
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).
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies