Outgoing queue state stays as inactive for a very long time
Henry
MSMQ for a very long time, and everything works great.
For our next release, we are going to use windows 2008 standard server, but
client will stays as XP. After we upgraded the server to windows 2008, we
have noticed the outgoing queue takes a very long time (10~20 minutes) to
swtich from inactive to connected states. When the XP client is rebooted,
the outgoing queue changes to inactive state and after the client comes back
online, the outgoing queue stays as inactive for 10~20 minutes before
becoming connected again. Once it is connected, the messages are flying back
and forth.
This long delay is a big problem for us. Any advice on what is causing this
long delay?
Thank you.
Henry
John Breakwell
10-20 minutes sounds WAY too long.
There are a couple of MSMQ registry values that directly control connection
times.
http://msdn.microsoft.com/en-us/library/ms703235(VS.85).aspx
1 WaitTime interval. This controls how long MSMQ will wait after closing a
connection before reopening it. This is to allow for network problems to
resolve themselves, should they have been the cause of the connection to
close in the first place. This applies to the client machine.
2 Cleanup Interval. Sets how long MSMQ keeps an idle connection open
before closing it. This applies to both client and server.
These shouldn't affect reconnecting after a reboot though.
An important area for indirectly impacting connection times is name
resolution.
If you are sending messages to the machine name of the Windows 2008 server
(rather than its IP address) then the name must be resolved to an IP address
before the connection can be established. Any problems with DNS will delay
the connecting machine when making a connection. Therefore an easy test here
is to send a message to the IP address of the server (DIRECT=TCP... rather
than DIRECT=OS...) and see if the connection is delayed.
If you still have problems after reviewing the above then I would recommend
looking at a network trace to see where the delays are coming in.
You may want to raise a support case with Microsoft to assist in the
analysis.
Cheers
John Breakwell (MSFT)
"Henry" <He...@discussions.microsoft.com> wrote in message
news:02F95905-FF8B-4A60...@microsoft.com...