How to config Tracking Event Processors and replay manualy in Axon 3 ?

Someone please help me to config Tracking Event Processors and replay manualy in Axon 3 ?

Thanks !

Hi,

check out these chapters in the reference guide:
https://docs.axonframework.org/part3/event-processing.html#configuring-processors

and
https://docs.axonframework.org/part3/spring-boot-autoconfig.html#event-handling-configuration

Cheers,

Allard

Thank Allard !

Can you tell me how to replay ?

This i my config :

`

@Inject
public void configure(EventHandlingConfiguration config) {
config.usingTrackingProcessors();
}

@Bean
public Serializer serializer() {
return new JavaSerializer();
}

@Bean
public TokenStore tokenStore(org.axonframework.config.Configuration config) throws SQLException {
return new JdbcTokenStore(springDataSourceConnectionProvider(), config.serializer());
}

@Bean
public SpringDataSourceConnectionProvider springDataSourceConnectionProvider() {
return new SpringDataSourceConnectionProvider(dataSource);
}

`

I can save to tokenentry table. But, token and tokentype colum is null and any external event can’t called.

Sorry, my english is noob :frowning:

Thanks again.

Hi,

No problem about the English, I think your question is still clear. :slight_smile:

Typically, to replay you’d just drop the token entry which is responsible of the event processing group which you’d want to replay.
So let’s say your query side has a group called ‘Users’, and you’ve made an adjustment to the ‘UserView’ in your database, thus you’re planning to update your ‘Users’ database by dropping that table and replaying.
You’d thus drop the ‘UsersToken’ from the ‘tokenStore’, when you’re application is down, and restart the app.
Axon will automatically figure out it doesn’t have a token for the ‘Users’ event processing group, so thinks it has to start handling events from the beginning of time.

You’re also talking about the fact that your token and tokenType columns are both null, so you’ve got a token entry inserted without the actual token and it’s type, correct?
I’m not completely sure what could cause this.
Are there any other interesting things to note about your set up?
Maybe that sheds some light on what’s failing in your set up.

Hope this helps!

Cheers,

Steven

Thank Steven so much :x

Hi Steven,

You'd thus drop the 'UsersToken' from the 'tokenStore', when you're
application is down, and restart the app.

Is it possible to trigger a replay while the app is running ?

I have a listener which is in charge of updating a remote service and had like to replay all events when I detect that something bad happened to the remote service. I tried to remove the token_store_entry from the listener but it does not seems to work (EventListener still see "original" lastToken).

Regards,
Clément

Hi Clément,

for optimization reasons, the tracking processor doesn’t read the token from the database each time if it has already read one. To force a replay while the application is running, you must shutdown the processor, then delete the token, and then start the processor again. This will force it to restart from the beginning.

Cheers,

Allard

Hi,

I recently came across this blog post that give a very instructive example: http://www.techjava.de/topics/2017/10/implementing-event-replay-with-axonframework/

To do exactly that.

Cheers,

Tim

Hi,

I’m wondering about replaying events while having multiple instances of my application.

Is this stopping and starting of processor still ok?

Assuming that code:

stopProcessor()

removeTokenEntry()

startProcessor()

when a processor is stopped on one instance and token_entry is removed then the second instance could try to update no longer existing token entry.

Is it a problem or possible scenario?

Regards,
Filip

Hi Filip,

If you’ve got two identical instances running, but containing the same ‘TrackingEventProcessor’, then yes, only calling the assumed code on one instance will cause the second to proceed with the existing token or create a new one on it’s own.
I’d recon that the scenario you’re sketching would create undesired behavior in your set up.
So to answer your question: it will most likely be a problem and yes it’s a a possible scenario.

I’d imagine we’ll cover for the described scenario in this issue though.

Hope this gives you some insights Filip.

Cheers,

Steven

Hi Filip,

I was just discussing this bit with Allard over here and I figured I missed something in answering your question; sorry for that!

So, if I understand your question correctly, you’re trying to figure out of the sketched scenario would be an issue if you’d want to recreate a view by replaying events.
In the scenario that you’ve got multiple instances taking care of a view, it’s better to stop all of those processor instances prior to removing the token.

If you’d for example stop instance X which had a claim on the token, instance Y sees that the claim has been released and will take it over.
If you’d then remove the token, instance Y wont see that change immediately, as it thinks it has claimed the token and thus will proceed with handling events in a normal fashion.
It’s thus better to stop all the processors prior to removing the token.

Once the removal has taken place, then you can start up all the instances again, upon one of these will create and claim the token initially and update the views accordingly.

Hope this helps.

Cheers,

Steven