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