Issues with tracking token when upgrading from 3 to 4

Imported from Google Groups
1

Hi,

We’re trying to move from 3.x to 4.x, but we have some issues with the tracking tokens.

We use MongoDB as the tokenstore in 3.x. This is in our AxonConfig

`

@Bean(name = “axonTokenStore”)
public TokenStore axonTokenStore(MongoClient client) {
return new MongoTokenStore(new DefaultMongoTemplate(client), new XStreamSerializer());
}

`

When we inspect the token stored in out token collection on MongoDB, the tokenType field has the value
org.axonframework.mongo.eventsourcing.eventstore.MongoTrackingToken

In 4.x we’ve kept things the same as much as possible for now, so no AxonServer yet, all events, tokens and sagas are stored in MongoDB, just like in our 3.x setup.
Our 4.x config looks like this (just a change to use the builders for the tokenstore)

`

@Bean(name = “axonTokenStore”)
public TokenStore axonTokenStore() {

Serializer tokenSerializer = XStreamSerializer.builder().build();

return MongoTokenStore.builder()
.serializer(tokenSerializer)
.mongoTemplate(defaultAxonMongoTemplate())
.build();
}

`

But when we start the application we get these errors:

2018-10-29 09:47:16.839 [EventProcessor[com.mn.stagportal.view.employee]-0] INFO o.a.e.TrackingEventProcessor - An error occurred while attempting to claim a token for segment: 0. Will retry later…
java.lang.ClassCastException: org.axonframework.serialization.UnknownSerializedType cannot be cast to org.axonframework.eventhandling.TrackingToken
at org.axonframework.eventhandling.tokenstore.AbstractTokenEntry.getToken(AbstractTokenEntry.java:117)
at org.axonframework.extensions.mongo.eventsourcing.tokenstore.MongoTokenStore.fetchToken(MongoTokenStore.java:147)
at org.axonframework.eventhandling.TrackingEventProcessor$WorkerLauncher.lambda$run$1(TrackingEventProcessor.java:726)
at org.axonframework.common.transaction.TransactionManager.executeInTransaction(TransactionManager.java:47)
at org.axonframework.eventhandling.TrackingEventProcessor$WorkerLauncher.run(TrackingEventProcessor.java:725)
at org.axonframework.eventhandling.TrackingEventProcessor$CountingRunnable.run(TrackingEventProcessor.java:588)
at java.lang.Thread.run(Thread.java:748)

So it appears that 3.x tracking tokens cannot be deserialized in 4.x…
After inspection (and a reset on a test system), we see that the value of tokenType in 4.x has changed to:

org.axonframework.extensions.mongo.eventsourcing.eventstore.MongoTrackingToken

Is there any guidance on how to migrate existing (mongo) tracking tokens? Is this a bug? Is this also an issue with JPA based token stores?

We really do not want to reset our whole application, but like to upgrade to 4.x and ‘just pick up where we left off’

Thanks,

Kind regards,

Danny

2

We have the same problem.

The tokentype in the database is org.axonframework.eventsourcing.eventstore.GapAwareTrackingToken, but this class has been moved to org.axonframework.eventhandling.GapAwareTrackingToken.

In the logs, we see: java.lang.ClassCastException: org.axonframework.serialization.UnknownSerializedType cannot be cast to org.axonframework.eventhandling.TrackingToken

How do we fix this?

3

Hi Danny, Any,

This is indeed an issue which should be solved by the framework so that the XStreamSerializer (which I assume both of you are using for the tokens) can coop with this package restructuring on the token’s end.

I have created the following ticket to resolve the issue.

The MongoTrackingToken should be an easy fix, as we can quite easily add the aliases needed in there.

That could thus be something you could do right away yourself Danny, if you’d want to.

For the GapAwareTrackingToken and GlobalSequenceTrackingToken we need to dig a little further how to resolve this, An.

I have slated this bug for release 4.0.1, which we are planning to release somewhere next week.

Hope this gives enough background to the problem at hand. We’re on it as we speak

Again, thanks for sharing!

Cheers,
Steven

4

PS. I’ve just created a PR which should resolve the problem at hand.

The plan deviated a little from the alias approach, to be more in line with how we resolved legacy code issues between Axon 2 and 3.
As shared earlier, we plan to release 4.0.1 somewhere next week, so stay tuned!

Cheers,
Steven

5

Hi Danny and An,

The PR I’ve shared earlier this day has been reviewed and merged.

Hence the only thing to wait for is the release.

In the mean time, you could leverage the solution I implemented there in your local project so that you can proceed with the migration.
Hope this helps you both out!

Cheers,
Steven

6

Hi Stephen,

Thanks for all the work! Really appreciate it.

One question though does this also “convert” the axon 3 tracking tokens to the axon 4 format when the tracking tokens are updated, or do they keep the “old” format?

Thanks,

Danny

7

Hi Danny,

the solution makes Axon 4 aware of the old format, and have them automatically convert to the new format after reading them. Once a token is stored, it’s the Axon 4 format.

Kind regards,

Allard

8

Hi,

Just to let you know,

All works fine now. We can switch from Axon 3.x to 4.x.

Thanks for all the help and the fix in the code.

Danny