NServiceBus Bus.Send().Register(callback) Not Working on IIS/Windows Server 2008

Question

I have been struggling with this problem for a few days now and I just can't seem to figure it out.

I have a simple WCF web service hosted on IIS and Windows Server 2008 R2. The implementation of the Web Service is as follows:

        var completionResult = new CompletionResult();
        var updateTextMessage = new UpdateText { TextTemplateId = textTemplateId, Text = text };

        var asyncResult = Global.Bus.Send(updateTextMessage).Register(x => completionResult = x.AsyncState as CompletionResult, null);
        asyncResult.AsyncWaitHandle.WaitOne(10000);

        if (completionResult.Messages != null && completionResult.Messages.Length > 0)
        {
            return ((UpdateTextResponse)completionResult.Messages[0]).ImageData;
        }

        return string.Empty;

I know that trying to use NSB in a synchronous manner is considered bad design but I'm just experimenting and I would really like to get this working. So the issue is that the message gets successfully sent to the remote endpoint and the message is processed successfully, but the reply message is just lost in the ether when the remote endpoint does a Bus.Reply. I am using the latest version of NSB and the strange thing is this works fine on my Windows 7 development machine. I have made sure active directory is off on both machines. I have also ran Wireshark on the receiving endpoint and sure enough I see the incoming message in the packet data. It seems that something is not jiving with IIS. I also switched the logging threshold to DEBUG for both endpoints and nothing unusual is going on. The sending endpoint says the usual "sending messages to..." Here is the code in my Application_Startup for the web component:

        Bus = NServiceBus.Configure.WithWeb()
            .Log4Net()
            .DefaultBuilder()
            .XmlSerializer()
            .MsmqTransport()
                .IsTransactional(false)
                .PurgeOnStartup(false)
            .UnicastBus()
                .ImpersonateSender(false)
            .CreateBus()
            .Start();

Here are the configs for the endpoints:

IIS Config (this side is not getting the response)

<MsmqTransportConfig InputQueue="Web.InputQueue" ErrorQueue="Web.ErrorQueue" MaxRetries="5" NumberOfWorkerThreads="1"/>
  <UnicastBusConfig>
    <MessageEndpointMappings>
      <add Messages="Messages" Endpoint="Node.Distributor.DataInputQueue"/>
    </MessageEndpointMappings>
  </UnicastBusConfig>

---------------------------------------------------------------

Endpoint which does the reply

<MsmqTransportConfig ErrorQueue="Node.ErrorQueue" InputQueue="Node.InputQueue" MaxRetries="5" NumberOfWorkerThreads="1"/>
<UnicastBusConfig DistributorControlAddress="Node.Distributor.ControlInputQueue" DistributorDataAddress="Node.Distributor.DataInputQueue" />

I also created two standalone NServiceBusHost applications to test communication and it worked successfully. I also hard coded the return address and replaced the .Reply with a .Send but specifying the actual destination and it still didn't work. So again it seems to be related to IIS. Any help would be greatly appreciated!

Answer 1

I solved the problem. Turns out the reason for the replies getting lost was due to the fact that I was referencing the distributor as such:

<UnicastBusConfig DistributorControlAddress="Node.Distributor.ControlInputQueue@10.1.4.58" DistributorDataAddress="Node.Distributor.DataInputQueue@10.1.4.58" />

But it turns out that the NServiceBus distributor doesn't like IPs. So I changed it to the following:

<UnicastBusConfig DistributorControlAddress="Node.Distributor.ControlInputQueue@HOSTNAME" DistributorDataAddress="Node.Distributor.DataInputQueue@HOSTNAME" />

and this solved the problem. I also had to update my hosts file in Windows since NSB/MSMQ uses hostnames. I am not sure if this is a bug in NServiceBus or if it is a known issue but it should really be documented if it isn't already.

Answer 2

Sounds like queue permissions to me. Check your queues on the WCF side to see if msmq can even deliver the message