DeadLetterQueue uses wrong Serializer to (de)serialize Tokens

[nils-christian]

Hi,

I am not entirely sure whether this can be classified as bug, invalid documentation or a missing feature.

Basic information

• Axon Framework version: 4.6.2
• JDK version: 11
• Complete executable reproducer if available (e.g. GitHub Repo): https://github.com/nils-christian/axon-issue-dlq-serialization

Steps to reproduce

Start the provided example. Please note that multiple conditions have to come together for this issue to appear:

• We have to use a DLQ (obviously).
• We have differently configured serializers for events and tokens (in our case we reconfigured the object mapper for the events and set the token-serializer manually by creating a custom token event store).
• We have to use a MultiStreamableMessageSource.

In our application all those conditions come together and make the DLQ unusable.

Now, the documentation of the serializer in the builder for the DLQ says: "Sets the Serializer to deserialize the events, metadata and diagnostics of the DeadLetter when storing it to a database.". This is not true, as it is also used for serialization and it is also used for (de)serialization of tokens as can be seen in the EventMessageDeadLetterJpaConverter. I think it should be possible to either configure the (de)serializer for all four classes independent from each other or maybe the DLQ should use the serializer from the token store. The first approach would probably be the easiest one. The DLQ could still use the current serializer as default for all four classes, making this change compatible with 4.6.2.

Expected behaviour

The application works.

Actual behaviour

The application crashes with a deserialization exception.

[CodeDrivenMitch]

Hello @nils-christian,

The reason for using the same serializer is that we are both in control of serialization and deserialization in the same component. So as long as we use the same for serialization as for deserialization, we should be fine.
What is the actual cause of the application's crash? Do you use a special token for the MultiStreamableMessageSource?

We could introduce the same serializer levels as Axon contains: events, messages, and generic as an improvement. But I'd like to understand the situation properly first

[nils-christian]

Hello @MORLACK,

While you are in control of the (de)serialization, you are not in control of the classes themselves, especially the event payloads. Our events use the builder pattern and contain various annotations. This is the reason why the default object mapper cannot handle them properly and why we have to reconfigure it. However, the modified object mapper cannot handle the tokens of the MultiStreamableMessageSource in a correct manner. And this is the reason why we need to configure different serializers (more precisely: different object mappers) for the events and the tokens. This is usually not an issue, but in the DLQ both elements are (de)serialized with the same object mapper so one of them is always (de)serialized in an incorrect way.

To provide a more extreme example: Assume that we (de)serialize the events with XStream and the tokens with Jackson (for whatever reason). This would be possible - just not with the DLQ (unless of course we would implement a custom serializer which is able to recognize the elements to be (de)serialized).

[CodeDrivenMitch]

Alright, thanks for the explanation. I'll create a PR that allows different serializers to be configured.

[CodeDrivenMitch]

Hello @nils-christian, I just merged the fix that will be able to resolve this issue for you. It will thus be included in 4.6.3

[nils-christian]

Thank you for the quick fix @MORLACK. I will try and test the fix before the release within our specific environment.

[nils-christian]

Sorry for the delay, @MORLACK. The fix works for our environment.