Suppose we have three projections (i, ii and iii) which are all in the same package and so they will all have the same processing group/tracking event processor.
Each projection handles the same event (albeit in a different way).
Now suppose the following scenario:
Two of the projections have business logic which succeeds.
One of the projections’ business logic will fail.
Although two projections succeed what I am observing is that because of the single failure, they all fail.
In the log I get message saying the TEP will try again in 60 seconds (and of course never succeeds).
I have a few questions regarding this behaviour:
Is this the expected behaviour?
Are they all failing because they are all in the same unit of work?
Is there a state transition diagram for a TEP available somewhere (I’ve not found anything in the reference docs)? This would really help understanding it.
This depends on the configuration, actually.
Event Handling Components (the projections are a type of Event Handling Component) in this example belong to the same Processing Group. Furthermore, they also belong to the same Event Processor. Thus, the Event Processor invokes all Processing Groups for a batch of events, which in turn will invoke your Event Handling Components.
If the failure is such that the transaction fails, then the entire batch will be rolled back. If the failure, however, does not break the transaction, then the rest should proceed. Have you configured any specific ErrorHandler or ListenerInvocationErrorHandler perchance? Give your description it seems that every failure will roll back the transaction, which signals your ListenerInvocationErrorHandler rethrows the error (like the PropagatingErrorHandler does).
Are they all failing because they are all in the same unit of work?
Yes, this is exactly the case. A BatchingUnitOfWork to be exact that deals with a batch of events.
Is there a state transition diagram for a TEP available somewhere (I’ve not found anything in the reference docs)?
No, there is not. We are adjusting the documentation around the Event Processor in the Reference Guide, which should make it more readable.
FYI, “bumps” wont necessarily help with a speedy response. Although AxonIQ is monitoring the forum and providing quite a lot of answers, the intent is for the entire community to help each other out. This thought, in combination with all the other work AxonIQ’s doing, means we can only spend so much time on this. Hence, waiting for a response might happen. If you need quicker responses to support questions from AxonIQ directly, setting up a dedicated support channel might be an idea.
Thanks for the reply Steven - as always it really helps to get the names of classes/interfaces which are doing the work behind the scenes. I hadn’t set up any of these additional error handlers and so it makes sense that the whole thing fails.
I thought I would just push my luck with the bump and maybe get a response. I hope it didn’t come off as rude!
