That’s brilliant. I have/had a problem with my cron jobs eventually stopping because of this error but I could never catch them. With each crash you lose a cron thread so, by default, you can survive 5 crashes and then you’re fresh out of luck. I up’d it to 20 threads and a weekly reboot. 
@rlkoshak
There is already a thread open for this. Personally, I don’t think this should delay 2.5. 
Actually, prior to 2.5 M2 (maybe 3?) Cron triggered rules had a pool of size 2. After that default was upped to size 10.
And back when I did see these errors I never had a problem with running it if threads, but there have been many changes since then.
Excellent! This is catchable. That should help us significantly. Although that looks like the standard “error occurred inside a timer lambda” log statement. We’re you able to capture the exception itself in the lambda?
Looking again at my stack capture …
at com.sun.proxy.$Proxy172.apply(Unknown Source) ~[?:?]
at org.eclipse.xtext.xbase.lib.IteratorExtensions.findFirst(IteratorExtensions.java:108) ~[?:?]
That looks like a $function.apply() in there, and we know those are prone to concurrency issues on the user side of DSL
It depends on how the lambda is defined and for that we need more context. For example, if you define a lambda outside a rule you have a real risk of concurrency issues. But if you define a lambda inside a rule, there is no chance that the lambda could be called from another rule because the lambda only exists inside the context on the inside of that rule. It gets destroyed at the end of the rule like any other local variable, unless it’s passed to createTimer in which case the whole context from the rule gets saved by the timer until it expires or is cancelled and it all gets garbage collected.
So seeing the call to apply does not necessarily mean it’s being called in a concurrency context. It might just be a local lambda being called. We’d need to see the code to know.