Messages stuck in outgoing queue
Markus Frank
I´m sending messages between a connected client (windows xp) and a server
(windows 2003 server) which runs fine when I have 2 applications ( VC++ )
sending from the client to an application on the server. The application on
the server deliveres a response back to the applications on the client. This
setup will create 2 public queues, 2 private queues (for reciving response)
and 2 outgoing queues on the client.
Whenn I then start the third application ( which creates 67 outgoing
queues ) this hangs the sending of the 2 other client applications and the
messages get stuck in the outgoing queues for a couple of seconds (until the
messages timeout?), why?? This doesn't happen every time, sometimes it works
fine!
Does anyone know what my problem is or what I can use to debug my problem?
Programming language: VC++
Using:
Microsoft Server 2003 SP2
Microsoft Windows XP SP2
Frank Boyne
news:uG2CHldI...@TK2MSFTNGP05.phx.gbl...
> Whenn I then start the third application ( which creates 67 outgoing
> queues ) this hangs the sending of the 2 other client applications and
> the messages get stuck in the outgoing queues for a couple of seconds
> (until the messages timeout?), why?? This doesn't happen every time,
> sometimes it works fine!
A couple of seconds seems like a very low value to have for a timeout,
especially if your client system is going to have 69 outgoing queues and
messages in all of them. I would typically recommend timeout values
that are at least a multiple number of minutes or even multiple tens of
minutes.
You may be running into some XP limitation here. For example, XP (and
all workstation versions of Windows) places a limit of 10 on the number
of simultaneous incoming TCP/IP connections. This probably isn't your
problem since your application sometimes works but t is a possible
cause.
http://support.microsoft.com/kb/314882
Assuming you are running XP SP2, you might be running into a limit
placed on the number of concurrent incomplete outbound connection
attempts. Once you hit the limit, subsequent connection attempts are
delayed. If connection attempts for some of the 67 outgoing queues
failed it might trigger this slow-down delaying all further connection
attempts. You could check for this situation by looking for Event ID
4226 Source TCPIP in the event log.
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows%20Operating%20System&ProdVer=5.2&EvtID=4226&EvtSrc=Tcpip&LCID=1033
Other than that, John Breakwell's blog has several other descriptions of
problems that cause messages to get stuck in outgoing queues
http://blogs.msdn.com/johnbreakwell/archive/2006/09/15/756091.aspx
http://blogs.msdn.com/johnbreakwell/archive/2006/11/02/msmq-messages-using-http-just-won-t-get-delivered-2.aspx
http://blogs.msdn.com/johnbreakwell/archive/2007/05/15/msmq-messages-using-http-just-won-t-get-delivered-3.aspx
http://blogs.msdn.com/johnbreakwell/archive/2007/06/28/msmq-messages-using-http-just-won-t-get-delivered-4.aspx
http://blogs.msdn.com/johnbreakwell/archive/2007/08/21/msmq-messages-using-http-just-won-t-get-delivered-5.aspx
http://blogs.msdn.com/johnbreakwell/archive/2007/11/02/http-7.aspx
http://blogs.msdn.com/johnbreakwell/archive/2007/06/28/why-does-msmq-lock-your-outgoing-queue.aspx
http://blogs.msdn.com/johnbreakwell/search.aspx?q=outgoing&p=1
John Breakwell (MSFT)
I'm pretty sure that all outgoing queues to the same destination will be
concentrated through a single network connection for performance reasons so
limits shouldn't be a problem in a one-client-one-server setup.
There is no guaranteed quality of service for the outgoing queues.
There is a thread pool that handles the creation of network connections and
the sending of messages waiting in outgoing queues.
The messages will be sent when the MSMQ service has got round to the
particular outgoing queue that you are monitoring.
The size of the messages and whether they are express or not will be
important in determining how quickly the thread is freed up.
There was a problem in the past where having many, many outgoing queues to
remote servers that were not available resulted in so many threads being
used in trying to connect that the MSMQ service had insufficient threads
left to do anything else. So now the thread pool has a finite size which may
be what is causing you the slight delay.
Cheers
John Breakwell
from TechEd Developers 2007
"Frank Boyne" <frank...@unisys.com> wrote in message
news:eMoRi3kI...@TK2MSFTNGP06.phx.gbl...
Markus Frank
from.
I have now enable MSMQ routing (when installing) on the server so now I have
a "Connected" on each queue when looking at the outgoing queues. When
starting the application it takes about 30 seconds to get a "Connected" on
each queue but when ready my application works properly!! But.... until all
queues have status "Connected" my application has the same problem as
before.
It seems that enabling routing on the server makes the application recover
(takes 30 seconds though) from trying to connect to clients on a different
subnet.
However... can I do anything about the 30 seconds delay at startup of my
application?
"John Breakwell (MSFT)" <Green...@msn.com> skrev i meddelandet
news:B74A3F36-E1A1-45D3...@microsoft.com...
Markus Frank
from.
I have now enable MSMQ routing (when installing) on the server so now I have
a "Connected" on each queue when looking at the outgoing queues. When
starting the application it takes about 30 seconds to get a "Connected" on
each queue but when ready my application works properly!! But.... until all
queues have status "Connected" my application has the same problem as
before.
It seems that enabling routing on the server makes the application recover
(takes 30 seconds though) from trying to connect to clients on a different
subnet.
However... can I do anything about the 30 seconds delay at startup of my
application?
"John Breakwell (MSFT)" <Green...@msn.com> skrev i meddelandet
news:B74A3F36-E1A1-45D3...@microsoft.com...
John Breakwell (MSFT)
impact on what you are trying to do, which is use a point-to-point
connection.
All routing effectively does is add an intermediate hop to the trip to help
messages get delivered when a point-to-point connection is impossible or
impractical.
If you installed routing on a 3rd machine then I could see a possible
improvement if going via the 3rd machine was more efficient than going
direct.
From the information you have given on your environment, I can see no reason
why routing is helping you at all.
I would recommend having a look at the setting for QMThreadNo which sets the
number of worker threads available.
A Windows XP client has a number of threads to handle messages = 3 x CPUs.
Check the MSMQ FAQ at:
http://download.microsoft.com/download/F/C/9/FC9989A2-DA75-4D96-B654-4BD29CF6AEE1/MSMQ_faq_updated.doc
18.2 Any scale considerations for the messages delivery mechanism?
"The Message Queuing service has a pool of worker threads that do most of
queuing and delivery work. All threads listen on a common I/O completion
port. When an I/O operation is ready, the operating system wakes up a worker
thread, which processes the result of the I/O, issues another I/O request,
and then waits again on the completion port. Responsiveness of the Message
Queuing service will reduce if all worker threads are blocked and none is
available. The number of worker threads can be controlled via the QMThreadNo
registry value."
Please try increasing this setting.
Cheers
John Breakwell (MSFT)
"Markus Frank" <markus...@gabria.se> wrote in message
news:ujRLaYSJ...@TK2MSFTNGP06.phx.gbl...