MSMQ Messages Are Stuck In The Outgoing Queue
Asked Answered
R

7

18

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 = '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.

Rambouillet answered 28/10, 2010 at 15:24 Comment(5)
I am facing the same issue. Mark, did you ever get the the bottom of this?Alley
I do not recall now. Anyway msmq has gazillion issues so we have just abandoned it. My advice - stay away from it.Rambouillet
I've added a bounty as we have the same problem. The messages just sit in the outgoing queue, even when using DIRECT=TCP.Ketty
We have long abandoned MSMQ, because of all the problems associated with it. My advice - follow suit.Rambouillet
Thanks for the advice. As no one could help even with the bounty, we have also ended up abandoning MSMQ in favour of RabbitMQ.Ketty
P
8

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

Paedogenesis answered 21/12, 2011 at 14:24 Comment(0)
R
8

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.

Rodl answered 22/10, 2012 at 20:54 Comment(2)
We have long abandoned MSMQ (good), .NET (so-so) and C# (sigh!) in favor of Java (:-(). But thanks, anyway.Rambouillet
For me it was to make sure both machines can ping each other using NetBIOS name. THXHealall
C
6

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.

Chaliapin answered 15/2, 2013 at 19:43 Comment(2)
Thanks. After spending hours trying to resolve a similar issue (my MSMQ was public and transactional however) nothing else helped. "Disable un-authenticated RPC calls" was the fix.Countdown
We saw the same issue. "Disable unauthenticated RPC calls" was checked. Un-checking this option bypassed the issue. We suspect the root cause is some kind of network level change, but this change got us working immediately. All of the outgoing queues instantly sent their messages to their destination queues.Clastic
S
4

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.

Sufism answered 29/6, 2015 at 5:50 Comment(2)
This helped me, thanx!Indict
FYI: The referenced links are NSFW!Herriot
A
1

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.

Alunite answered 5/11, 2012 at 18:11 Comment(0)
G
1

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).

Gumbotil answered 29/7, 2021 at 23:37 Comment(0)
G
0

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.

Gemagemara answered 10/3, 2011 at 15:39 Comment(1)
outgoing queues are always created.Paedogenesis

© 2022 - 2024 — McMap. All rights reserved.