Hi,
We use Axon 4.0 and Spring Boot 2 with Kotlin lang and I have an issue with replying events on error in eventHandler or SagaEventHandler.
It is my application.yml file:
2 tracking processors with different names.
This is one of event handler:
I throw artificial exception for check that tracking works. Let’s debug it:
And when I got the event, I see that replayStatus is REGULAR.
When I throw artificial error I expect that it will reproduce event and trigger that eventHandler again after 1,2,4…30, 60 seconds every time. But I can’t reproduce it. After throwing exception it will not call handler again.
And I use this code in my config if it is necessary:
P.S. Does it has and issue to migrate from axon 4.0 to 4.2? Or it will be simple and we and our production db will not catch troubles?
Hello TibidibiDox,
A Tracking Event Processor will only enter “retry mode” (mind you, this is not a replay) if the exception thrown from your Event Handling Component (the RegistryEventHandler in this case) is bubbled up towards the internals of the Tracking Event Processor.
In short, the framework provides two levels of error handling when it comes to Event Handling:
- The ListenerInvocationErrorHandler, which handles exceptions thrown by the Event Handling Components you write.
Defaults to the LoggingErrorHandler.
- The ErrorHandler, which handles exceptions thrown within the Event Processor.
Defaults to the PropagatingErrorHandler.
The reason you do not see the retry mechanism kicking in, is because the ListenerInvocationErrorHandler, which is defaulted to the LoggingErrorHandler, catches your RuntimeException and simply logs that it has occurred.
If you want your Event Handler to enter this retry mechanism, you should replace the ListenerInvocationErrorHandler for a PropagatingErrorHandler, which ensure the exception is thrown further up the chain. Mind you, this behaviour is not always desired.
If the Event Handling Component in question updates query models for example and you enforce it to retry instead of proceed with other models, you will start serving stale data to any part of the application which is interested in your Query Models.
By the way, the Reference Guide has the following on this topic, which would be a suggested read if you try to adjust this behaviour.
Lastly, the ReplayStatus is part of the replay functionality given to you through the Tracking Event Processor (which is described here).
Note that to utilize this functionality, you will have to call the TrackingEventProcessor#resetTokens() method.
Concluding, you should be able to simply upgrade between minor and patch release, always.
Only between major versions can you expect breaking changes.
Thus, you should be able to safely update to 4.2.
Hope all this helps you out TibidibiDox!
Cheers,
Steven