无效字母更改类型后，如何反序列化无效字母消息? [英] How do I deserialize a dead lettered message when dead lettering changes the type?

问题描述

我正在尝试编写一个死信处理程序服务，该服务从死信队列中读取消息，然后根据类型，内容等对消息进行某些处理.

I'm trying to write a dead letter handler service that reads messages off of a dead letter queue and then does something with the message based on the type, contents, etc.

在我的C#应用​​程序中，我正在使用EasyNetQ.我有一个称为MyMessage的基本消息类型，然后有许多子类型. EasyNetQ序列化消息，将消息发送到交换机，从队列中拉出然后将消息反序列化回原始类型都没有问题.

In my C# application, I'm using EasyNetQ. I have a basic message type called MyMessage, and then a number of subtypes. EasyNetQ doesn't have a problem serializing the messages, sending them to an exchange, pulling them off the queue and then deserializing the message back into the original type.

但是，如果我在死信处理程序中将AdvancedBus设置为使用MyMessage类型从死信队列中使用，死信消息将开始进入错误队列而不是死信队列.显然，当邮件为空字母并且无法反序列化时，该邮件会以某种方式更改.

However, if I setup the AdvancedBus in my dead letter handler to consume from the dead letter queue using MyMessage type, dead letter messages start going into the error queue instead of the dead letter queue. Apparently, the message gets changed somehow when it dead letters and can no longer be deserialized.

有什么办法可以解决这个问题?

Is there any way to get around this?

我甚至可能从根本上误解了这个问题.如果队列中没有EasyNetQ使用者，则死信队列会按预期工作，但是一旦有使用者，它就会阻塞并开始将所有消息放入错误队列.我什至尝试使用基本的IMessage类型而不是我的类型.没有不同.仍然会出错.

I may be even fundamentally misunderstanding the problem. If there's no EasyNetQ consumer on the queue, the dead letter queue works as expected, but as soon as there's a consumer, it chokes and starts putting all messages in the error queue. I even tried consuming the base IMessage type instead of my type. No difference. It still errors.

推荐答案

事实证明，EasyNetQ在使用队列之前先查看队列中的所有消息.如果注册的使用者之一正在寻找无法反序列化的类型，EasyNetQ会将其从队列中拉出并转储到错误队列中，而不是让使用者自行处理错误.

It turns out that EasyNetQ looks ahead at all messages on a queue before they are consumed. If one of the registered consumers is looking for a type that it won't be able to deserialize, EasyNetQ pulls it off the queue and dumps it in the error queue, rather than just letting the consumer handle the error itself.

在我的情况下，我有一个超类"MyMessage"，使用者正在使用它来预订队列.然后，生产者正在发布MyMessage子类型的消息.问题在于，生产者和使用者位于不同的程序集中，尽管他们都了解MyMessage，但只有生产者才知道子类型. EasyNetQ无法反序列化，因为它不知道整个消息的模式.一旦将子类型包含在参考中，它便开始工作.

In my case, I had a supertype "MyMessage" that the consumer was using to subscribe to the queue. Then, the producer was publishing messages of subtypes of MyMessage. The problem was that the producer and consumer were in different assemblies, and while both knew about MyMessage, only the producer knew about the subtypes. EasyNetQ wasn't able to deserialize because it didn't know the schema for the entire message. Once I included the subtypes in a reference, it started working.

就像Hosepipe一样，它是用来读取错误队列的，这是不同的，但是仍然需要处理，因此感谢您的引用.

Looks like Hosepipe is for reading off of the error queue, which is different, but still something I need to handle, so thanks for the references.

这篇关于无效字母更改类型后，如何反序列化无效字母消息?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！