Query side - how to process only new events after a bounce?

When our ‘query’ application is bounced, it reprocesses all events, not just the unprocessed ones. We want to process only new ones.

We have an Axon framework application (v4.2.1) running that connects to an Axon Server. The application seems to be correctly configured to persist the token store, as I see the token_entry table created and constantly being updated. The token has the sequence that I would expect it to have:



To configure the JDBC persistence, we added JPA and driver dependencies, and respective configuration in the application.properties.

org.springframework.boot spring-boot-starter-data-jpa com.microsoft.sqlserver mssql-jdbc

Using Eclipse, I stop and start the application, the

@EventHandler public void on(OrderPlacedEvent event, TrackingToken trackingToken) throws Exception { ... }

is executed for every event that the Axon Server knows about. If no new events were added while the query application was down, I wouldn’t expect any events to be processed.

Is my understanding of how this CAN work through configuration wrong? I’m 99% sure I’m missing some Spring-Boot configuration that ties this together. While the configuration is easy to wire-up, it’s a bit overwhelming figuring out what all is needed. Right now, we use mostly defaults and have very little configured via spring-boot so far. It’s like the information is being stored correctly, but the system doesn’t know to use the Token Store. So far, we haven’t added JDBC Token configuration as the documentation seemed to indicate it should be automatically hooked up based on persistence dependencies.

Any help would be greatly appreciated.

(I just saw a very similar posting here: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/axonframework/oL-zsuYuteA I too am seeing “Fetched token: null for segment: Segment[0/0]”)


The therapeutic event of documenting everything and then asking for help, led us to the cause of the problem.

spring.jpa.hibernate.ddl-auto was set to “create” instead of “none”. Each time the JVM was restarted, the tables were re-created and we didn’t notice it.

Sorry for the noise. Hopefully this will help prevent someone else from getting stuck on a silly mistake.