MSMQ Messages Are Stuck In The Outgoing Queue

Although my question looks similar to some already found on SO, those post did not help me, so here it is:

Given:

• Two machines on the same segment (naturally in the same domain, actually on the same desk)
• Both machines are Windows 7 workstations
• Both machines have disabled firewall
• Both machines see each other (ping works)
• There is a private non transactional message queue test on one of them.
• The sender machine has HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\SimpleClient\@BinaryEnabled 开发者_JAVA技巧= 'Yes'
• The queue owner sends a message from another machine
• The message is stuck on the outgoing queue, never reaching the target.
• When sent from the same machine (i.e. locally) the message arrives OK.

The message is sent using the following code:

var q = new MessageQueue(@"FormatName:Direct=OS:il-mark-lap\private$\test");
q.Send(string.Format("Test message sent at {0} from {1}", DateTime.Now, Environment.MachineName));

Where il-mark-lap is the address of the machine with the queue.

What on earth do I have to do to make the thing work?

Thanks a lot.

I think I found the answer to this issue, I was having what appears to be the same problem, mine only got stuck after not sending messages to the client for 10 minutes though. Take a look at this KB article, it may help you. Also, in my case it had nothing to do with restarting, so don't let that throw you off, I did exhibit the symptoms in the netstat and messages would initially go through when the client was first started up.

http://support.microsoft.com/kb/2554746

I just dealt with the problem, here are the steps that I took in order to resolve it:

Get the DTCPing utility from Microsoft, run it on the machines that use MSMQ, the DTCs must be able to talk to one-another in order for MSMQ to work.

Troubleshooting MSDTC issues with the DTCPing tool

This in turn made me realize that MSMQ is highly dependant on NetBIOS names - the machines must be able to ping each other by using NetBIOS names alone.

Once this is done, make sure that you restart ALL Message Queueing services (both on sending machine and on destination machine as it needs to be able to perform a reverse NetBIOS operation).

In my case, once I got the DTC going with NetBIOS name resolution - restarted the services - everything started working magically.

I highly recommend that you visit this page for additional resources.

I had this problem today. To resolve it we had to open the Message Queuing properties dialog of the receiving server and on the Server Security tab uncheck the box for "Disable un-authenticated RPC calls". Also, on the private queue Properties | Security tab we changed the security to grant Everyone Full Control. In my case the machines are on the same segment, but not on the same domain. The queue is non-transactional. We are using IP Addresses for the endpoint bindings (WCF), NetBIOS/DNS is not in play.

I had an issue where we had 2 servers sending messages to a third. Only one server's messages were being received. The messages from the other one were stuck in the outgoing queue as 'unacknowledged'.

The problem was because all computers were cloned VM's and had the same QMId in the registry key: HKLM\Software\Microsoft\MSMQ\Parameters\Machine Cache. We reinstalled MSMQ on the servers which fixed the problem.

The answer is quit easy. Ensure you can telnet ports 1801,135,2103 & 2105 from both the source machine to the destination and vice versa. Also make sure MSMQ is running on both machines.

If a server suddenly refuses to receive messages (causing another server to have messages queue in the Outgoing queue), this may be because of the Journal messages size limit.

MSMQ will silently refuse messages if the server's journal queue backlog exceeds 1GB in size. This can be validated by looking at C:\Windows\System32\MSMQ\ and its subdirectories.

When journal queue messages are removed and the size no longer exceeds 1GB, it should immediately begin accepting messages again (without necessitating restarting the Message Queuing service).

Normally private queues in a LAN can sends messages to each other. But sometimes a private queue may be unreachable and causes others to create outgoing queues... Don't know why.