Long delay sending first message after idle period
solbr...@gmail.com
I have spent a lot of time trying to find the answer to this but have
been unsuccessful thus far... hoping someone can help me out.
The problem:
I have noticed that the MSMQ service on the sending machine seems to
go through some sort of a "warm up" period when attempting to send the
first message after a period of inactivity (say 30 mins) OR if send
the first message to a new remote recipient (i.e. different ip). This
warm up period seems to last anywhere from 90 secs to as much as 150
secs but once the first message is sent, the rest are instantaneous.
The environment:
- Windows 2003 SP1 w/ the following installed MSMQ components: Common,
Active Directory Integration
- all messages use DIRECT format names (ex. "FORMATNAME:DIRECT=TCP:
192.168.0.1\private$\QueueName")
- use .NET 2.0 Messaging API to send/receive messages from custom
applications (new MessageQueue object is opened/closed each time a
message is sent)
- all messages are non-transactional
- journaling/dead-lettering is disabled
- sender id is not sent (i.e. MessageQueue.AttachSenderId = false)...
done to avoid delays in checking security credentials
- use BinaryMessageFormatter to serialize/deserialize the body
I have read old articles that say to try setting a couple of registry
entries to help avoid MSMQ delays:
AlwaysWithoutDS = 1
CleanupInterval = some large value
I tried this and did not seem to make a difference (I think these
settings are for Win 2000 only bcs they do not show up in the Windows
Server 2003 Resource Kit Registry Reference).
What I suspect is happening during this "warm up" period is that the
MSMQ is trying to locate the remote MSMQ service and initialize the
connection however I have not been able to confirm this (and I am not
sure why this would take so long). Would this have anything to do with
Active Directory (even though we are using DIRECT format names)?
I would appreciate any suggestions.
Thank you.
Mike
John Breakwell (MSFT)
MSMQ is designed to send messages as fast as it can. If the service is
running then messages will fly.
In your case I would normally suspect name resolution. As your problem
occurs after a period of inactivity, this usually corresponds to the IP
addresses in the cache being flushed. But you are using IP addresses so it
can't be that.
You could try adjusting WaitTime down from it's current 60 seconds to see if
that helps (probably won't)
909401 A message takes longer than expected to be delivered or expires
prematurely in Message Queuing 3.0 ...
http://support.microsoft.com/default.aspx?scid=kb;EN-US;909401
Using DIRECT format means no interaction with Active Directory so no need to
worry about AlwaysWithouytDS, etc.
The changes you mention won't help in your situation.
Talking about registry documentation, the registry reference documents are
woefully out of date:
http://blogs.msdn.com/johnbreakwell/archive/2007/02/14/tracking-down-msmq-registry-documentation.aspx
What is the status of the outgoing queue during the delay? Is it "Connected"
or "Waiting to connect"?
I would look in Network Monitor traces to follow the connection traffic.
There are 3 different steps you should see:
1 MQPIng exchange to check that destination is available
2 Traditional 3-way handshake.
172983 Explanation of the Three-Way Handshake via TCP/IP
http://support.microsoft.com/default.aspx?scid=kb;EN-US;172983
3 MSMQ parameter exchange to configure the network connection
after which messages will flow.
The 3 steps should all happen in a fraction of a second.
Cheers
John Breakwell
Frank Boyne
news:1185493088.1...@w3g2000hsg.googlegroups.com...
> I have noticed that the MSMQ service on the sending machine seems to
> go through some sort of a "warm up" period when attempting to send the
> first message after a period of inactivity (say 30 mins) OR if send
> the first message to a new remote recipient (i.e. different ip). This
> warm up period seems to last anywhere from 90 secs to as much as 150
> secs but once the first message is sent, the rest are instantaneous.
I've tried waiting up to sixty minutes between sends and so far as I can
see, Netmon 3.1 shows MSMQ traffic between the systems in question
immediately after I click on the Send button of my test application. Of
course there are all sorts of differences between your environment and
mine so my inability to reproduce the problem isn't necessarily
significant.
If you are still able to reproduce the problem, and would be willing to
download and use Netmon 3.1 to capture all the network traffic from both
the good send and the delayed send we might b able to tell something
from that network trace. It would also be useful if you could put some
marker in the Netmon trace to show where the Send was performed -
perhaps ping some known working address immediately before and
immediately after your application calls send.?