I’m following the axon-springboot example shared by Allard (https://github.com/abuijze/bootiful-axon).
My understanding so far is: (please correct me if I have misunderstood some of the concepts)
Events are raised and stored in the event store/event bus (Mysql) (using EmbeddedEventStore). Now, event processors (TrackingProcessors - in my case) will pull events from the source (MySql - right?) and event handlers will execute the business logic and update the query storage and message published to RabbitMQ. First question is where, when and who publishes this message to the RabbitMQ (used by statistics application which has the message listener configured.)
I have configured the TrackingProcessor to try the replay functionality. To execute the replay I stop my processor, delete the token entry for the processor, start the processor and events are replayed and my Query Storage is up-to-date as expected. Second question is, when the replay is triggered and Query Storage is updated, I don’t see any messages being published to the RabbitMQ…so my statistics application is out of sync. Am I doing something wrong?
First of all, a correction: it is not the Tracking Processor or the updater of the view model that sends the messages to RabbitMQ. The Events are forwarded to Rabbit as they are published to the Event Bus.
The answer to your first question: messages are published by the SpringAmqpPublisher, which connects directly to the Event Bus, and forwards any published message to RabbitMQ as they are published.
To answer your second question, let’s clarify how replays work, first. While it’s called a “replay”, essentially it’s more a “reset”. The Tracking Processor uses a TrackingToken to remember its progress of processing the Event Store. When the token is deleted (or just not yet available), the Tracking Processor starts processing from the beginning of the Event Store.
You never reply an entire application, just a single (Tracking) Processor. Just imagine: you re-publish all messages to RabbitMQ again, other components are triggered again, unaware of the fact that these are “old” messages, and user-confirmation emails are sent again, orders placed again, etc. etc.
If your Statistics are out of date, it’s because they aren’t part of the same processor and aren’t rebuilt together with the other element. RabbitMQ doesn’t support “replaying”, since it doesn’t remember the messages after delivering them.
Any model that you want to be able to rebuild, should be managed by a Tracking Processor.
Thanks Allard for the quick response and clarification. Much Appreciated!
“it is not the Tracking Processor or the updater of the view model that sends the messages to RabbitMQ” - Understand, I guess I was not clear in my question, my apologies. I meant “Event processors (TrackingProcessors - in my case) will pull events from the source (MySql - right?) and event handlers will execute the business logic and update the query storage”.
Regarding the answer to the second question -
“You never reply an entire application, just a single (Tracking) Processor.” - Agree, in my case I’m just replaying a single processor (deleting token for that particular processor) and it does the job of updating my query db. No dramas here, but as you have suggested ‘The Events are forwarded to Rabbit as they are published to the Event Bus.’ which means messages won’t be published by the ‘SpringAmqpPublisher’ when replay is triggered. As statistics app is running in a different JVM, hence its not part of same processor. Can you suggest any work-around to keep it in sync when replaying this processor? (would like to keep it in separate JVM/microservice)
I don’t understand why these components would be out of sync after a replay. Essentially, with a replay, you end up with the state as before the replay started. The reason you do a replay is because it allows you to capture additional information in your view model, that you didn’t have before.
If the problem is that the statistics module doesn’t have statistics from before it was started, then that’s because that module doesn’t use a “replayable” source. If that’s important, then don’t configure it to use the Event Store instead, for example. That’s all part of the design choices you’ll need to make. In the sample app, this was merely a showcase on how things could be done.