1
votes

I have a service that is configured to handle a command object. In the Handle method I am throwing an exception in specific business cases. When this occurs it send the error to the Error queue and I think the Particular Management service is processing the Error queue. It is my understanding is that the Particular Management service will monitor the Error queue and process the messages, that is to say, mine the metadata and persist it to RavenDB. Lastly, it should forward the message to the Error.Log queue. Regrettably, every message seems to get routed to the Service.Management.Errors queue. Presumably, because the Particular Management service handler is failing.

If I look the Extension Headers of the messages in the Service.Management.Errors queue, I see the following information:

<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

at NServiceBus.Unicast.Transport.TransportReceiver.TryProcess(TransportMessage message) in c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus.Core\Unicast\Transport\TransportReceiver.cs:line 235 at NServiceBus.Transports.Msmq.MsmqDequeueStrategy.Action() in c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus.Core\Transports\Msmq\MsmqDequeueStrategy.cs:line 170

Since the ServiceInsight Particular Management service is presumably supposed to be generic in nature, I would assume that it does not need to know about the actual types of messages. Meaning, I don't have to throw my Message dll's into the directory of the service (correct?). Thus implying that it simply mines all of it's data to persist to RavenDB by simply reading the Extension Headers.

So with that ground work in place. Can someone please validate or invalidate my understanding of how ServiceInsight works and is configured. Secondly, my error looks like it is an error in NServiceBus.Core. Am I supposed to add some DLL's or something. Of is there another likely candidate for causing this issue that I am simply overlooking.

1
Can you post the message schema of the message that ends up in the error q?. Also is this happening for all message types? What happens when you run the error handling sample and generate an error message, does that fail as well?Indu Alagarsamy
You may be over-thinking this. Almost all cases of NullReferenceException are the same. Please see "What is a NullReferenceException in .NET?" for some hints.John Saunders
Did you ever figure this out? This is happening to us as well. We're not actually using ServiceInsight, but if the management service is running it fills up our MSMQ storage with these errors.jon without an h

1 Answers

0
votes

We were having a similar problem, and although our problem was probably pretty specific to us, I'll share it just in case.

Most of our services use NServiceBus 4.0.3 with XML serialization, but we have one older service that is using NSB 3.3.1 and binary serialization. That service was logging to the audit queue, and when the Particular Management service tried to read those messages, it would fail. I'm not sure what the source of the error was, due to NSB re-throwing the exception and losing the original stack trace. I suspect that it is trying to read a header that isn't there. It may also be due to using binary serialization.

Our solution was to turn off auditing for that one older service.