We sometimes have multiple event handlers listen to the same event, both synchronous processors. With one event handler updating state in the DB, the other (e.g.) triggers some emails based on the same event. We chose this approach to have these concerns isolated, i.e. the event handler that updates the DB should not be concerned with other side-effects of the event.
However, sometimes the secondary event handler depend on the state in the DB,
so we need to impose a fixed order in which the event handlers are called.
If I understand correctly, this is possible (when using Spring), but I don’t find it mentioned in the documentations.
To impose the order we:
annotate all involved event handlers with org.axonframework.config.ProcessingGroup (order seems only applicable within one processingGroup),
use org.springframework.core.annotation.Order to determine priority.
Is this approach correct?
If so I think it makes sense to add this to the documentation.
We also tried this approach to order a SagaEventHandler vs a normal EventHandler, but this did not seem to work.
Is it possible to impose an order involving SagaEventHandler and EventHandler?
You can indeed introduce an ordering between Event Handling Components within an Event Processor.
And like you suggest, that’s done by ensuring both Event Handling Components are part of the same processing group and adding the @Order annotation from Spring, given your Event Handling Components are Spring Beans.
Ensuring Event Handling Components are part of the same Processing Group can be done through several methods:
Ensure that each Event Handling Component is contained in the same directory path. Axon will take that path as the ‘processing group name’ and hence they’ll be part of the same group.
Add the @ProcessingGroup as a class level annotation to your Event Handling Component, were both components you wish to be part of the same processing group, have the same value contained in the annotation.
Option 2 is the more concrete approach, so something I’d recommend. And for ensuring the ordering you’d then add the @Order as a class level annotation as well.
So yes, you’re suggested approach was correct.
My guess why it’s not part of the Reference Guide (yet), is because it works for Spring users only. Axon does not do anything specific with the annotation, it’s Spring which ensure the ordering among those components when they’re being called, or for Axon inserted in the handlers list.
Imposing an ordering on your @(Saga)EventHandler annotated functions is not possible. I’d also like to share that I think it’s a lot safer to not assume any event ordering at all (apart from an aggregate-created-event which is always prior to it’s preceding events), as it is quite hard to guarantee that events will always happen in that exact same order. It’s thus safer to take the stance you cannot count on an ordering to begin with.
Let’s hope this thread may serve as documentation for coming interested parties ;).
Regarding:
I’d also like to share that I think it’s a lot safer to not assume any event ordering at all (apart from an aggregate-created-event which is always prior to it’s preceding events), as it is quite hard to guarantee that events will always happen in that exact same order. It’s thus safer to take the stance you cannot count on an ordering to begin with.
Just to be clear, now you’re talking about event ordering, while my question is about order of event-handlers (and we can rely on ordering there (right?)).
You’re remark sparks two questions:
“an aggregate-created-event which is always prior to it’s preceding events” - something seems off here. Either you’re talking about the event that creates the aggregate, in which case prior holds, or you’re talking about event created by an aggregate, in which case (hopefully) preceding holds
I can see how a handler (talking about a class here, as apposed to one method) (saga or otherwise) that handles events from different sources (e.g. multiple aggregates or timers) cannot be guaranteed the order of these events. But I expect the events from a single aggregate to be handled in order, is this correct?
I just want to be sure I understand correctly. And if I didn’t so far, I must have a firm look at our system :P.
Yes, agreed! And I’ll have a look at adding it to the reference guide any how, but want Allards input on that as well.
Now for your follow up questions:
I mean the event which sets the aggregate identifier of your aggregate. That’s typically the first event published from an aggregate, so you can assume it’s the first event you’ll receive for a given aggregate. I should’ve used ‘following’ i.o. ‘receding’ in that sentence, sorry for the miscommunication there.
Ah, I typically view the handler as the actual function, and the Event Listener or Event Handling Component the class. Again, I could’ve been clearer on that point, sorry for that! And yes that’s a fair assumption. An Event Listener handling events from several aggregates will receive it’s events in the order they’re persisted to the event store. Hence, the sequence order of events within an aggregate should be guaranteed. Between different aggregates is another story.
Hi,
I have the same problem, and I have tried @Order, but it does not work with an event handler vs a saga event handler, even with multiple normal event handlers.
Is it possible to impose an order involving SagaEventHandler and EventHandler which listen to the same event?
Thank you for your answers,
Maya.
在 2018年2月2日星期五 UTC+8下午7:44:37，Steven van Beelen写道：
yes, it’s indeed impossible to impose order on Event Handlers versus Sagas. It is possible to impose order on Event Handlers, but only if they’re assigned to the same processing group. Note that, by default, each handler is assigned to a processing group (and a processor) with the name of the package of the handler class.
we are using an old version of Axon (version 2.2). So far, we didn’t need an order of event handlers, but time has come.
I have seen this article: https://blog.trifork.com/2014/02/13/new-in-axon-2-1/, which says using @Ordered annotation we can achieve what we want, but that is not the case, and I can still can not force the ordering.
Our EventHandler classes are in different packages.
In 2.2 version there is not an option for ProcessingGroup packages.
you can only indicate ordering among event handlers, if they are assigned to the same processing group. In Axon 2, we used different naming, and called them “clusters”. You’d need to use the ClusteringEventBus and make sure handlers are assigned to the same cluster, which is needs to be configured with a OrderResolver.
I just checked, and the SimpleEventBus does not allow ordering to be indicated.
You might want to consider migrating towards Axon 4 ;-). A lot of things have become a lot simpler to do.
