我有一个配置为处理命令对象的服务。在Handle方法中,我在特定的业务案例中抛出了一个异常。当这种情况发生时,它会将错误发送到错误队列,我认为特定的管理服务正在处理错误队列。我的理解是,特定的管理服务将监视错误队列并处理消息,也就是说,挖掘元数据并将其持久化到RavenDB。最后,它应该将消息转发到Error.Log队列。遗憾的是,似乎每条消息都被路由到Service.Management.Errors队列。可能是因为特定的管理服务处理程序出现故障。
如果我查看Service.Management.Errors队列中消息的扩展标头,我会看到以下信息:
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.ExceptionType</Key>
<Value>System.NullReferenceException</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.Message</Key>
<Value>Object reference not set to an instance of an object.</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.Source</Key>
<Value>NServiceBus.Core</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.StackTrace</Key>
<Value>System.NullReferenceException: Object reference not set to an instance of an object.
at NServiceBus.Unicast.Transport.TransportReceiver.ProcessMessage (TransportMessage message) in c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus.Core\Unicast\Transport\TransportReceiver.cs:line 357在NServiceBus.Unicast.Transport.TransportReceiver.TryProcess(TransportMessage消息处)在c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus.Core\Unicast\Transport\TransportReceiver.cs:line 235中在c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus.Core\Transports\Msmq\MsmqDequeueStrategy.cs:line 170中的NServiceBus.Transports.Msmq.MsmqDequeueStrategy.Action()处
由于ServiceInsight特定的管理服务在本质上应该是通用的,因此我假设它不需要知道实际的消息类型。也就是说,我不必把我的消息dll放到服务的目录中(对吗?)。因此,这意味着它只是通过读取扩展标头来挖掘所有数据以持久存储到RavenDB。
因此,基础工作已经到位。有人能验证或无效我对ServiceInsight的工作原理和配置的理解吗?其次,我的错误看起来像是NServiceBus.Core中的错误。我是不是应该添加一些动态链接库之类的东西。还有另一个可能导致这个问题的候选人,而我只是忽略了这个问题。
发布于 2014-02-12 23:00:16
我们遇到了类似的问题,尽管我们的问题可能是针对我们自己的,但我还是会分享它,以防万一。
我们的大多数服务使用带有NServiceBus序列化的NSB4.0.3,但我们有一个较旧的服务使用NSB3.3.1和二进制序列化。该服务正在记录到审核队列中,当特定的管理服务尝试读取这些消息时,它将失败。我不确定错误的来源是什么,由于NSB re-throwing the exception和丢失了原始堆栈跟踪。我怀疑它正在尝试读取一个不存在的头。这也可能是因为使用了二进制序列化。
我们的解决方案是关闭对该旧服务的审计。
https://stackoverflow.com/questions/19231332
复制相似问题