Axon 4 with Axon Server: Multiple query nodes and projection rebuild.

Imported from Google Groups
#1

Hi All,

Just started playing around with Axon 4 w/ Axon Server after using Axon 3 for a few small micro services previously.

First of all, very nice work. A substantial portion of our code previously was all just configuration that allowed us to deploy and scale the command, query, and UI/API components independently of each other, and having a look at the giftcard-demo it looks like that may have become a whole lot easier when using axon server.

I am hoping however that someone can point me in the direction of some documentation or code about the “magic” rebuilding of projections that happens when an App/Microservice starts and connects to the event store on Axon Server.
Specifically I am looking for any info on how this works when running multiple query nodes that use the same persistence (same mongodb) for the projections. At the moment whenever a new query node starts, or is restarted, it rebuilds the projection, so for the period of time that it is rebuilding the projections the other query nodes are effectively getting the state of the current rebuild.

If anyone could point me at any information with regards to this it would be greatly appreciated, as I haven’t been able to find anything.

Thanks,

Tony

#2

Hi Tony,

from your description I would guess that you may need to configure a persistent TokenStore that is shared among all your query nodes. The TokenStore tracks which events stored in AxonServer your application has consumed already. Per default Axon 4.0 with the spring-boot-starter autoconfig sets up an InMemoryTokenStore that will loose the TokenInformation upon application reload - thus rebuilding all projections since all events get replayed. Have a look at the docs in https://docs.axoniq.io/reference-guide/1.3-infrastructure-components/event-processing#token-store.

For my query-side application I configured a JPATokenStore pointing to a PostgreSQL database (it needs to be the same database for all instances of the same application, so if you have a query-microservice and a command-microservice you would need two databases. if you scale either of them, the replicas should also point to the same database). You can configure hbm2ddl to setup the schema automatically, I decided to use Liquibase migrations from the start.

For reference I also link two of my earlier questions in this group regarding the topic:

Just a side-note: if you use Sagas in your application, consider also to set up a SagaStore (JPASagaStore is working similar to the JPATokenStore). It will keep track of the state of your Sagas across application restarts.

#3

Thanks Jacob, will have a look.