MSMQ calls over HTTP not reaching destination queue
Asked Answered
B

1

2

I have a WCF service that uses MSMQ communication, when i run the service on my local netwrok, i configure the service endpoints in the client config files to point to the host computer, for example if the endpoint specified on the service host is:

<endpoint address="net.msmq://localhost/private/MsmqService/MyMsmqService"
         binding="netMsmqBinding" bindingConfiguration="test" contract="MsmqService.IMyMsmqService">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>

I configure my client to send messages to this endpoint:

<endpoint address="net.msmq://192.168.1.5/private/MsmqService/MyMsmqService"
         binding="netMsmqBinding" bindingConfiguration="test" contract="MsmqService.IMyMsmqService">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>

Obviously 192.168.1.5 is the IP of the host computer, this works like a charm. I host my service in IIS 7, I activate the MSMQ listener on IIS, give appropriate access right etc (Pretty much everything in Tom Hollanders article) and I can even access my service over http in my browser, but when I create clients of my service which is hosted in IIS and configure the endpoints in the client App.config, naturally I configure my clients to this:

<endpoint address="net.msmq://ServiceHostPublicIP/private/MsmqService/MyMsmqService"
         binding="netMsmqBinding" bindingConfiguration="test" contract="MsmqService.IMyMsmqService">
        <identity>
            <dns value="localhost" />
        </identity>
</endpoint>

That's where things go wrong. The messages I send keep getting queued in an outgoing queue on the client machine: DIRECT=OS:[ServiceHostPublicIP]\private$\MsmqService\MyMsmqService and the state of the queue is always: 'Waiting to Connect'. I've tried setting the queue transfer protocol to SRMP, my queue name is the same as my service name as is required by IIS, and I've given appropriate permissions on the queue. Has anybody recently encountered this problem before? Any Ideas? It'd be great if somebody could share a working sample of MSMQ over HTTP if they had one.

Any help would be greatly appreciated. Thanks in advance.

Buonarroti answered 28/2, 2012 at 18:58 Comment(0)
B
4

I managed to fix this, my messages were getting stuck in an outgoing queue on the client machine, "DIRECT=TCP:HOSTSERVERIP\private$\MsmqService/MyMsmqService.svc" the state of the queue was 'Waiting to connect' and the next hop was the destination servers public IP, so the client couldn't connect to the destination queue even though it could ping the destination servers public IP, turned out the port 1801 which is used by MSMQ to listen to incoming traffic was not open on the router of the network on which the service host machine resided, after opening port 1801 everything is working like a charm. It's such a fundamental issue that i guess many didn't bother mentioning it in their articles/tutorials. Hope this helps somebody later on.

Buonarroti answered 29/2, 2012 at 8:5 Comment(3)
Could you please answer #9631849 ?Sargeant
How does this answer the question? With MSMQ over HTTP you only should need to open port 80 and not any other ports (that's the whole point!!) The outgoing queue suggests that the WCF clients are not attempting to send the messages over HTTP (otherwise you'd get an HTTP prefix and not an OS prefix)!Delmerdelmor
Well I remember back when I was doing this, i was invoking the service from my home computer, the service was hosted on the server in our office, the messages weren't reaching the queue on the host server and somewhere on the MSDN forums somebody had suggested opening port 1801 on the host's network, so i forwarded incoming traffic to port 1801 to the host computer and it worked...what you say makes sense and that's why i didn't even bother opening that port, but it was the solution for me at the time. And to be honest, I can't tell you why it worked but it did.Buonarroti

© 2022 - 2024 — McMap. All rights reserved.