How exactly subscribing processors interact with the Axon Server?

I wonder how exactly publishing events to the Axon Server works when the subscribing processor handles the event? When does remoting happen?

There was an excellent (but somewhat old) presentation about the Axon framework’s internal working when Axon Server didn’t exist yet (https://axoniq.io/blog-overview/a-messages-journey-through-axon-framework). The presentation explains that event publishing happens before event handling. I guess the order is different when we have Axon Server in the picture.

While speaking about it, it would be great to see that presentation updated to the framework’s latest state, including Axon Server and tracking processors. For me, it was and still is a great learning resource.

Tnx

The SubscribingEventProcessor (SEP) is invoked by a SubscribableMessageSource implementation. Virtually all scenarios, this would be the EventBus, which in an Axon Server environment would thus be the AxonServerEventStore.

What is very important to know in this case, is that Axon Server is a streamable solution for events in a distributed environment. Not a subscribable version. Hence, if you would use Axon Server and have a SEP in place, said SEP will only receive events which have occurred on that exact JVM.

So, a SEP will only receive events from an AxonServerEventStore if those events have been published locally. Ergo no remotting is in place for subscribing sources through Axon Server.

On the note of the article, I’ve shared with our marketing team to have a look at updating said article at some point in the future. The value is understandable, but the effort was rather substantial as well by that (former) colleague of ours. Thus I am unsure when such an update or new instalment would arrive.

Actually, I was wondering when appending to the event store happens. My wording wasn’t accurate.

After quick source browsing, my understanding is that events are appended (and sent over the wire) in the commit phase of the root unit of work. At that time database transaction is still open, so if remoting fails all database-related work from subscribing event processors will be rolled back. Is this right?

That assumption is correct Damir!
The same thread, and thus UnitOfWork, is used for both command handling, “event sourcing handling” (in case of an Event Sourced aggregate), event publication and event handling in any SubscribingEventProcessor.

Thus any failing operation in an Event Handling Component the SEP is in charge of can rollback the entire UnitOfWork, thus undoing the storage of an event.

This is definitely the main part why the SEP is (no longer) the default Event Processor in Axon Framework. Having the processes updating your Query Model influence if the Command Model succeeds is typically not what you would want when doing CQRS.

A SEP might prove useful if the model it updates is part of the Command Model for example, like when you want to support set based validation.