Partilhar via

You will need to restart MSMQ if you add network connections

  • Artigo

Back in the old days when MSMQ first came out, machines were pretty static in their configuration. Once you had built them, they didn't change much and the network was always up and running by the time MSMQ started. Even those rich enough to have laptops with PCMCIA in had to reboot to get the cards picked up so nothing was dynamic. Now, years down the line, technology is much smarter - you can buy USB wireless network cards that burst into life when they are plugged in, for example.

MSMQ, though, isn't really aware of this development. During service startup (and only then), MSMQ calls GetAddrInfo() to get all the available addresses of the machine. It then binds to, and listens on, all of them but any dynamically created networks that appear afterwards will not be noticed as MSMQ does not currently (which includes MSMQ 5.0) monitor for them. 

Easy way to check if this is the case is to run "NETSTAT.EXE -A -N" at the command prompt - there should be no entries for <New IP address>:1801 as MSMQ won't be listening on this port.

[[Thanks to Xin Chen for the explanation]]

[[Edited January 12th, 2010]]

Another example of a problem scenario is where APIPA (Automatic Private IP Addressing) is used. If the machine is configured to "obtain an IP address automatically" but there is no DHCP server available (through fault or design) then a 169.256.x.x address will be generated for the network card to use. Unfortunately APIPA has to wait 60 seconds for the DHCP client to give up trying to get an address and by that time MSMQ has already started up.

Comments

  • Anonymous
    July 28, 2009
    Thank you.  This lead me to fix my troubles involving a failure to send to remote private queue.  My net topology is small and perhaps a little on the quirky side.  It involves a notebook (A: Vista 64) connected wireless to a workstation (B: Vista 32).  The workstation hosts dialup internet via USB aircard and shares this out using ICS.  I'm not sure at what point things got out of hand, but no messaging could be sent to any remote private queues.  I suspected it had something to do with the way ICS is routing (or not).  The message would sit in the temporary/outgoing queue with a "waiting to connect".  Using netstat to check the status of listeners, I could see the syn_sent on port 1801 for the IP of the workstation.  I had found the IP of the workstation through a ping of it's workgroup name.  So it's like MSMQ had requested a TCP port from the workstation, but no ACK back.  FINALLY!  I came upon this thread and it occurred to me I might try a restart of the MSMQ service.  That cleared it up.  However, should I be disturbed that this was a required action?  In my opinion, it makes MSMQ seem a bit flakey.  Do I need to restart the MSMQ service as a best-practice?  Just in case network interfaces have changed.  ~ Adam

  • Anonymous
    July 29, 2009
    Hi Adam, This blog post is specific to the situation when a sending machine gets a new network connection after the MSMQ service has started. Does the network configuration on the notebook change, depending on the state of the workstation? What does IPCONFIG, for example, show when you can't send messages? If the notebook's network interface is not active at boot time then MSMQ won't be able to make use of it until its service is restarted. I agree that this does give MSMQ a negative appearance. Hopefully it will be looked into for MSMQ 6.0.