NServiceBus Unicast debugging

0
votes

I have several websites that push messages to a remote MSMQ (so they can then be published to a list of subscribers). Because the websites don't consume messages -- it's just a send-and-forget set up -- I only have the following config in my web.config for the sites:

<UnicastBusConfig>
  <MessageEndpointMappings>
    <add Messages="MyNamespace.Messages" Endpoint="PublishingInputQueue@remoteserver" />
  </MessageEndpointMappings>
</UnicastBusConfig>

I'm trying to chase down a bug where intermittently messages appear to be successfully sent via Bus.Send(..) (no exceptions are thrown), but the messages never make it to the destination queue.

Is there any other configuration I can do to help diagnose this issue? Is there a way to set up an error queue for messages that fail with UnicastBus? Is it as simple as establishing an Error queue in the MsmqTransportConfig (which I currently don't have in my config?)

Update

A little more context...

  • As mentioned in the comments, I'm seeing a bunch of messages apparently piled up in the outgoing message queue of the web server(s). (I can't view the actual messages, but can see a count > 0 when clicking on "Outgoing Queues" in Computer Management.)
  • The publisher that created the destination queue (on remoteserver) has .IsTransactional(true) in the NServiceBus startup code.
  • The clients that push to that queue via UnicastBus has .IsTransactional(false) in its NServiceBus startup code.
  • This doesn't seem to cause an issue for other client websites that push to this destination queue. HOWEVER:
    • The webservers that don't seem to fail are Windows Server 2008
    • The webservers that do fail are Windows Server 2003
    • No clue if that makes a difference or not
  • The domain user the application pools run under has full permissions to the destination queue.
1
nservicebus
Check the dead letter queue to see if any messages ended up there. – Udi Dahan
Yeah, I'm seeing what appears to be messages backed up in the outgoing queue on the web server. (This is all new to me.) Thanks for the suggestion, I'll let you know what I find. – kdawg

1 Answers

0
votes

For completeness sake:

It turned out that the Active Directory objects used for the MSMQ service on the servers were out of sync. I believe it occurred when our DevOps team created a single server instance, set it all up, and then cloned it for the other server instances in the cluster. This initial server worked correctly (explaining the intermittent success), but the cloned instances had an out-of-sync AD object for MSMQ. Deleting the objects to allow for recreation fixed the issue.