@Laura_Winnen, well, if skipping is not fine when something fails, why did you ask how you would skip a failed event? Maybe I am not following your use case here…some elaboration would be helpful to better understand your situation, either from you or from @Koen_Verwimp.
On any note, you can make the ListenerInvocationErrorHandler
smart, as I said earlier. If you check the method you’d implement when creating a custom ListenerInvocationErrorHandler
, it gives you the following inputs to react on:
public interface ListenerInvocationErrorHandler {
void onError(Exception exception, EventMessage<?> event, EventMessageHandler eventHandler) throws Exception;
}
- You get the
exception
, so that you can validate what you want to do on the given exception.
- Furthermore, you can check the exact event which was handled that caused that exception. I believe this answers your first question too, @Koen_Verwimp. You’d simply now what event failed, as the
ListenerInvocationErrorHandler
provides it to you.
- You even get the entire
EventMessageHandler
which was used during invocation. This could, essentially, allow a retry of handling the event if required.
I hope this clarifies the position of the ListenerInvocationErrorHandler
. Granted, the default implementations provided don’t sound like they’re suited for your situation. Then again, the situation begins to sound very specific, which wouldn’t allow a generic-framework implementation anyhow.
Now, there are still two questions left from your end too @Koen_Verwimp (assuming 1 has been answered through my explanation of the parameters on the ListenerInvocationErrorHandler
:
- The
TrackingEventProcessor
will simply proceed with the defined batch size whenever you’ve pushed it into error mode. “Pushing it into error mode” means you have propagated the error up through all levels, thus on the ListenerInvocationErrorHandler
and the ErrorHandler
. The TEP thread which failed will move in an incremental back-off retry loop, but the chances are pretty high another TEP thread will simply pick up the token and proceed as usual. Thus, even if the failed thread would go for lower batch size, it wouldn’t really cause any impact. This is arguably one of the reasons why we’re working on another type of Event Processor which provides more flexibility.
- I am uncertain why you feel the
ListenerInvocationErrorHandler
(LIEH) isn’t suited here. The LIEH is the place which is first invoked when your event handler fails. This allows you to choose what you want to do when that exception occurs. Do you want it to fail hard? Rethrow the exception. Do you want to retry? Invoke the given eventHandler
. Do you want to ignore or skip the event? Simply do nothing.
To conclude, and as I feel it’s the most important gist out of the above: if you want an event handling exception to not cause your batch of events to rollback, simply catch the exception in the ListenerInvocationErrorHandler
and ignore that it happened.