infrastructure-components | React components that let you configure | Frontend Framework library

What you're missing @GoldFLsh, is either of these two:

1. Correctly reference the EventProcessor behind your LetterSchedulingHandler
2. Define the @ProcessingGroup of your LetterSchedulingHandler

What you might have read in the Reference Guide on Event Processors, as that any Event Handling Component (read your LetterSchedulingHandler for example) will be grouped with other Event Handling Components in either a subscribing or a tracking event processor.

You have however not configured any processing group name at this stage. This means the LetterSchedulingHandler's processing group will be defaulted to the package name of the handler. Hence, in your properties file you should use the package name instead of LetterSchedulingHandler to define it as being subscribing.

What's clearer though, is to add the @ProcessingGroup annotation on the LetterSchedulingHandler, giving it a clear name you can then use in the properties file.

Lastly, the fact you are not correctly referencing the Event Processor is why you'll see replays of events. Axon defaults to a TrackingEventProcessor which keeps track of how far it is with handling events of the stream. Without a persistence unit to store these TrackingTokens in, it will always start from scratch.

Complete answer here: https://github.com/AxonFramework/AxonFramework/issues/1006

Quoted answer:

Now to resolve the issue you're having - it seems that you want to reset some of your query models at start up of the application. You are however hitting a configuration order problem in this scenario, where the TrackingEventProcessor have not been started yet, whilst the configuration file you've created is already being called.

Note that we have plans to be more specific on the ordering when specific beans are created (potentially with Spring application events if you'd ask me) - we are however no there yet, so please bear with us until this rework has been performed.

For now, the simplest approach you can take, is have a dedicated replay service. You'd than wire this ResetService/ReplayService with the EventProcessingConfiguration and have it contain a void resetProjectors() method. I'd suggest calling this method at a point in time where you're certain the application has been completely wired up (for example by handling some of the Spring application events).

Thanks again to the Axon development team.

This aspect of event processors can be configured in application.yml/application.properties

I think this depends on what you count as state, but I assume that from the point of view your looking at it, yes, the EventProcessor implementations in Axon are indeed stateless.

The SubscribingEventProcessor receives it's events from a SubscribableMessageSource (the EventBus implements this interface) when they occur. The TrackingEventProcessor retrieves it's event from a StreamableMessageSource (the EventStore implements this interface) on it's own leisure.

The latter version for that needs to keep track of where it is in regards to events on the event stream. This information is stored in a TrackingToken, which is saved by the TokenStore. A given TrackingEventProcessor thread can only handle events if it has laid a claim on the TrackingToken for the processing group it is part of. Hence, this ensure that the same event isn't handled by two distinct threads to accidentally update the same query model. The TrackingToken also allow multithreading this process, which is done by segmented the token. The number of segments (adjustable through the initialSegmentCount) drives the number of pieces the TrackingToken for a given processing group will be partitioned in. From the point of view of the TokenStore, this means you'll have several TrackingToken instances stored which equal the number of segments you've set it to.

The SequencingPolicy its job is to drive which events in a stream belong to which segment. Doing so, you could for example use the SequentialPerAggregate SequencingPolicy to ensure all the events with a given aggregate identifier are handled by one segment.

At this point (Axon 4.0) the framework does not allow you the option to register DispatchInterceptors per command payload type directly. So what you're suggesting to do, the if-blocks/switch-statements, is the best thing you could do at this point.

Although I am not certain how fine grained your permission checks are, what you could do is have some form of permission annotation on the commands, with a specific value/enum you need to set on it. That way you do not have to tie in your payload type into the dispatcher directly, but could just check if the annotation exists and if so, check it's value for the kind of permission check which should be performed on it.

That would very likely result in a far smaller if-block/switch-statement than checking per payload type.

Your application can very well both have the, what's internally called, GenericeJpaRepository and the EventSourcingRepository along side one another. What you can't do however, is have both repositories for a single Aggregate implementation.

Luckily I see that that's what you're looking for, different ways of storing different aggregates. How to configure this depends on one thing though. If you are in a Spring environment, simply annotating your state-store Aggregate with JPA annotations is sufficient. If you omit these JPA annotations, it will automatically default to being an Event Sourced Aggregate. If you are not using Spring however, you can configure this by using the AggregateConfigurer#jpaMappedConfiguration for state-stored Aggregates and AggregateConfigurer#defaultConfiguration for the Event Sourcing approach.

Simply put though, you very likely do not have to implement your own Repository. Sorry to hear the documentation led you to believe this was the case, I'll ensure we'll adjust that.

In regards to your set validation question, I am not sure to call it 'solving the problem' more as to moving it to the database layer. As the article you share suggests, that is one of the solution to solve the problem, but it comes at a price.

As the Reference Guide currently does not specify this, I am gonna point this out here. Currently you've roughly got two approaches you follow when distributing an Axon application or separating an Axon application into (micro) services:

1. Use an full open source approach
2. Use AxonHub / AxonDb

Taking approach 2, which you can do in a developer environment, you would only have to run AxonHub and AxonDb and configure them to your application. That's it, your done; you can scale out your application and all the messages are routed as desired.

If you want to take route 1 however, you will have to provide several configurations

Firstly, you state you use RabbitMQ to route commands and events. In fact, the framework does not simply allow using RabbitMQ to route commands at all. Do note it is a solution to distribute EventMessages, just not CommandMessages. I suggest either using JGroups or Spring Cloud to route your commands in a open-source scenario (I have added links to the Reference Guide pages regarding distributing the CommandBus for JGroups and Spring Cloud).

To distribute your events, you can take three approaches:

1. Use a shared database for your events.
2. Use AMQP to send your evens to different instances.
3. Use Kafka to send your evens to different instances.

My personal preference when starting an application though, is to begin with one monolith and separate when necessary. I think the term 'Evolutionary Micro Services' catches this nicely.

Any how, if you use the messaging paradigm supported by Axon to it's fullest, splitting out the Command side from the Query side after wards should be quite simple. If you'd in addition use the AxonHub to distribute your messages, then you are practically done.

Concluding though, I did not find a very exact request from your issues. Does this give you the required information to proceed, @Federico Ponzi?

After having given it some thought, I think your solution is quite simple. You are using Spring Boot and you want to set up your EventStore to use MySQL. For Axon to set the right EventStorageEngine (the infra component used under the covers to read/write events), you can simply add a dependency on the spring-boot-starter-data-jpa. Axon it's auto configuration will in that scenario automatically notice that you have Spring Data JPA on your classpath, and as such will set the JpaEventStorageEngine.