Replaying Events and Subscribing Event Processors

Imported from Google Groups
#1

Hi

I startet with project based on spring boot. Using the default configuration axon uses subscribing even processors. For my case these kind of processors made a perfect fit up until now.

When modifying tables of my query model I wanted to use the replay feature of event source based systems. However when reading the documentation of axon framework replaying is only possible with tracking event processors.
(In my case I want to replay all events since the very beginning)

Question:

  • Is there really no way to replay events when using Subscribing Event Processors?
  • What is the reason for this limitation?

Cheers
Marco

#2

Hi Marco,

Yes, that is indeed true. The reason is that subscribing processors don’t have control of which events they receive. So, they’re not able to reset anything. Theoretically, you could redeliver events to the subscribable event source that the processor listens to. However, this is exactly what Tracking Processors are good at. They keep track of their position and have more control on the event stream.

I hope this explains it.
Cheers,

Allard

#3

Hi Allard

Thanks for your answer.

Subscribing Event Processors have the advantage that they are not asynchronous. In small Applications this fact can ease the development.

  • The call to commandGateway with sendAndWait returns after the event handlers have been executed as well. Theses eases UI-Development
  • You have the possibility to Rollback everything in case of an issue during event handling
    In my case I want to replay everything. Therefore a tracking is not needed in my point of view. Just replay all events stored in the eventstore.

Why shouldn’t that be possible?

Cheers
Marco

#4

Hi Marco,

It is not so much that it is not possible, but you’d have to create that yourself.

From the framework perspective we see a lot of benefit to actually tracking where an Event Processor is in handling events.

Additionally, the benefits you note might hold for small apps, but definitely do not hold when you start going large scale, or distributed.
So, regarding your two benefits:

  1. If you want to return a view upon the CommandGateway.sendAndWait() call, I have a different approach you might look at. This leverages the Subscription Query from the QueryGateway. When a command comes in, you’d first subscribe to the results of the view which will eventually be created. Then, you publish the command, and after a given time your Subscription Query will get the update automatically. This short sample project from my colleague Frans shows how to tackle this.
  2. Although this might seem nice, this couples your command and query side together. Typically, the Command side shouldn’t be influenced by any failures of the Query side, as CQRS, the segregation of the command and query side entails. It might be easier to think of the command as a fire-and-forget action. The command expresses the desire to perform some action, and if that decision was made, that’s when you’re done in that (mental) thread of execution. The Query side reacts on what has happened as a separate unit. Additionally, if you’d be using a TrackingEventProcessor and you’d have an exception, a fix in your code and then a replay potentially could solve the issue at hand.

So, to answer your last question, it is not not possible, it is just not designed that way.

Hope this helps you out Marco.
Feel free to post more questions on this forum!

Cheers,
Steven

#5

Hi Steven

Thanks for your answer! I will definitely have a look at the possibilities that are provided by the the query gateway.

Cheers
Marco