0
votes

We use NServiceBus in our web application and have recently found that at times there have been a few messages that just sit in the outbound queue despite a connected state however never leave. The quickest solution to remove them is to restart the MSMQ service. A problem I came across with this was that when restarting or stopping the MSMQ service the CPU jumps to 100%.

Has anyone come across this and find a way to prevent this high load. I don't like the idea of an outage just due to stopping a service? One way I know is to use send only mode however this isn't ideal.

UPDATE: Configuration code used within the global.asax application start:

  IBus bus = Configure
            .With()
            .DefaultBuilder()
            .FileShareDataBus("c:\\storage")
            .XmlSerializer()
            .MsmqTransport()
            .IsTransactional(false)
            .PurgeOnStartup(false)
            .UnicastBus()
            .ImpersonateSender(false)
            .CreateBus()
            .Start(() => Configure.Instance.ForInstallationOn<Windows>().Install());
1
what version of nsb are you using?Andreas Öhlund
I'm using nsb 3.3.0. I've additionally updated the question to add the configuration code.Ryan

1 Answers

0
votes

I think your issue might be related to the issue Incorrect MSMQ perms cause high CPU in web application on GitHub which is closed, but targeted for the 4.0 release which is not yet out.

The issue is that NServiceBus is trying to read from the queue, but there is no queue! So it gets into a tight loop of Check-Error-Retry that pegs the processor.

Taking down MSMQ is a fairly angry thing to do to a web server that needs it. If you need to do this in production, I would advise taking the server out of the load balanced pool (I'm assuming/hoping that you're using a load balancer) and then restart MSMQ, then IIS. If the server isn't handling requests then a short period of high CPU activity shouldn't really be a big deal.

When 4.0 comes out it should take care of the CPU issue, but I would still advise taking the server out of rotation because otherwise Bus.Send() will throw while MSMQ is unavailable.