使用服务（ServiceBase）的MSMQ C＃实现

Question

I will be using MSMQ in C# to read messages; and I am putting this in Window Service so on OnStart I will start reading messages using queue.Receive method which would be blocking/synchronous call. And OnEnd method I want to stop the queue with queue.Close(); queue.Dispose().

Is there any drawback of this approach ?

Thanks Ocean

Answer 1

This is incorrect approach. OnStart is called once when service starts, you should put initialization logic. For example start thread that will call Receive in a loop.

Answer 2

Your approach looks fine to me. My only advice is to make sure that every machine on which you intend to deploy the Windows Service is either in the same Domain, or are in Domains with mutual trust and that reside within the same Forest . I had a problem recently with a solution that I inherited that utilised MSMQ, and that worked much the same way as you have proposed above. It was tested as working on a single domain with no performance issues. Unfortunately, the client was in the process of a merger, and when it came time to implement the solution across the wider company it turned out that the solution had to be implemented on machines that existed in different domains in different Forests, in which case MSMQ wont work at all and another approach entirely had to be used.

Answer 3

This is a fairly common pattern, but it has some drawbacks.

First, you should consider using a thread pool (or the .NET parallel libs in 4.0) to process your messages asynchronously. Whether or not your queue reader can be asynchronous depends a lot on your transaction pattern. Will the processing be atomic?

Second, you should also consider using a timer (System.Timers.Timer) which you start in your OnStart and end in your OnEnd, and which reads one or more messages from the queue on each timer event.

Third, you should seriously consider just using the WCF MSMQ binding, which handles a lot of the complexity of this stuff.

See: http://jamescbender.com/bendersblog/archive/2009/04/04/the-one-where-i-talk-about-the-msmq-binding.aspx