I have an issue where we updated a few of our Saga classes to contain a new eventhandler method.
We now see a lot of exceptions occurring where the existing saga’s cannot be deserialized because apparently the serialVersionUID has changed (nobody realized this would happen by adding a method).
Caused by: org.axonframework.serializer.SerializationException: An error occurred while deserializing: SomeSaga; local class incompatible: stream classdesc serialVersionUID = 2342437250069672294, local class serialVersionUID = -1349044639818330111
I now wonder how we can correct this issue as I have to deal with old saga’s with the old serialVersionUID and new saga’s which have been given a new serialVersionUID. I know there’s a concept of upcasting events, but I have trouble finding a source if this concept can also be applied to saga’s, Has anyone been in a similar situtation?
I am curious why java serialization is used for the sagas. Did you explicitly configure the JavaSerializer in your app ? Other than that I would try to explicitly define the previous uid from the stacktrace in that saga class.
Java serialization is used because that is the default of Axon framework. Had no idea there were alternative choices (well, until I ran into this issue).
Anyway, we solved our issue by overruling the serialization process and updating the serialVersionUID where necessary. This ensure that all saga’s with the old and the new serialVersionUID are being processed again. Not exactly the situation anyone would like to find themselves in, but it was really the only way we could think of to save the situation.
Java serialization was the (unfortunate) default for Sagas in Axon 2. That has been changed in Axon 3, where the XStreamSerializer has become the default.
Good to know about XStreamSerializer in Axon3, I will need to read more about it.
We use Axon2. We have faced Java deserialization problems when either a new event has been added or the event data has been changed. These problems surface in the various event handlers.
Is that expected because we used the default Java deserialization? Could we have done this in a better way (using XStreamSerializer in Axon2)?
Changing event classes requires you to write an upcaster to convert between the event formats, the serialization mechanism is not going to help you there. Event serialization defaults (i think) to xstream.
Jorg
Upcasters are only necessary if you make changes that are incompatible with the serializer. In Axon 2, the Java Serializer was used in certain cases. That’s unfortunate, because that serializer requires an upcaster for almost any change. And it’s a binary format, making upcasters harder to build.
I recommend staying away from the JavaSerializer as much as possible. Use JacksonSerializer for events or the XStreamSerializer.
