MSMQ Trigger Services using 100% CPU

[Jason LaFollette]

I'm working on an MSMQ project for a client and running into an
interesting problem. We have 3 queues (A,B, and C), each with 1
trigger and 1 rule attached.
The rules call a method in a COM object (really just a wrapper for a
com visible .NET assembly). All three triggers/rules take a message
from the queue, parse it, and place it into the database. The server
is a dual P4 processor machine running Windows 2003 Server Edition,
and is dedicated only to running MSMQ related code. The trigger is
set to use a pool of threads between 5 and 20 in size.

Queue A is the only queue that gets a consistently high volume of
messages, about 10 per second. Queues B and C only see a message
every few minutes. At seemingly random intervals, anywhere from hours
to days between occurrences, the CPU usage for trigger services will
spike to 100% (cpu is normally around 20%) and all processing of queue
messages on all three queues stops. We have let the machine run in
this state for up to a day, but CPU stays at 100% until the trigger
service is stopped and restarted.

The problem does not seem to be caused by an issue with the particular
message being processed at the time. Logging indicates that the spike
happens at many different points in code and that no exception blocks
are being hit within the code. The messages that are in the queue
when the spike occurs also process just fine after the service is
stopped and restarted.

I understand that if the trigger code was causing the problem, much
more detail would be necessary for anyone to suggest a solution. What
I'm really looking for is whether anyone has encountered a similar
situation and found it to be a bug or setup issue with MSMQ and
triggers. I would also be interested to know if anyone has a similar
system running without this issue.

Any help would be greatly appreciated.

--Jason

[Doron Juster [MSFT]]

When this happens again you can zip the msmq log file
%windir%\debug\msmqlog.bin and attach it to your reply. It may reveal what's
the problem.

If it doesn't then I'd suggest you open a case with Microsoft support. The
standard method to troubleshoot this is to take two memory dump of the
triggers process, separated by a few seconds and analyze them.

Thanks, Doron
--
This posting is provided "AS IS" with no warranties, and confers no rights.
.

"Jason LaFollette" <Jason.La...@gmail.com> wrote in message
news:b155f742.04101...@posting.google.com...

[Muhammed Ismail [MSFT]]

What version of MSMQ and Trigger Service are you using?

You might be running into this issue:
330090 FIX: Trigger Service Causes CPU Usage to Increase to 100 Percent When
http://support.microsoft.com/?id=330090

You can download a new version of the Trigger Service (one that will
recognize the hotfix in the article) here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8086a653-c1fd-4ae4-
9a38-561156efbf6a&DisplayLang=en

--
Sincerely,

Muhammed Ismail
mis...@online.microsoft.com

Please do not send email directly to this alias. This alias is for
newsgroup purposes only.

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
>From: Jason.La...@gmail.com (Jason LaFollette)
>Newsgroups: microsoft.public.msmq.programming
>Subject: MSMQ Trigger Services using 100% CPU
>Date: 11 Oct 2004 15:50:34 -0700
>Organization: http://groups.google.com
>Lines: 36
>Message-ID: <b155f742.04101...@posting.google.com>
>NNTP-Posting-Host: 63.240.227.67
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 8bit
>X-Trace: posting.google.com 1097535034 21984 127.0.0.1 (11 Oct 2004
22:50:34 GMT)
>X-Complaints-To: groups...@google.com
>NNTP-Posting-Date: Mon, 11 Oct 2004 22:50:34 +0000 (UTC)
>Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.s
ul.t-online.de!t-online.de!news.zanker.org!news.cs.univ-paris8.fr!proxad.net
!postnews1.google.com!not-for-mail
>Xref: cpmsftngxa06.phx.gbl microsoft.public.msmq.programming:15914
>X-Tomcat-NG: microsoft.public.msmq.programming

[Jason LaFollette]

"Doron Juster [MSFT]" <Dor...@online.microsoft.com> wrote in message news:<#oPlD1Gs...@TK2MSFTNGP11.phx.gbl>...

Thanks Muhammed and Doron for your input. We opened up a ticket with
microsoft, installed a debuging app and generated a stack trace /
thread dump for all the running threads. The problem was traced to a
3rd party DB2 driver from Neon Systems (Shadow Direct). The driver
would crash occasionally when two threads made a simutaneous request
for a connection. We are trying a different version of the driver to
remedy the situation. I will post a followup if we find a final
solution.

Thanks
Jason