1

I have an asp.net webforms application that users will be interacting with. When the user selects certain items from the site and clicks a button for processing. The webapp will add a message to msmq for each item the user selects.

The part I am trying to figure out:

What type of application should my second application be if its job will be to process the queue (msmq). The key is that this second application needs to sit idle until my asp.net webapp tells it that the 'Process' button was clicked, then it will go ahead, check the queue and process it. I do not want it to constantly check the queue every minute or so, only on command check the queue.

Windows Service, Web Service, Web API? I currently have a Windows Service that checks the queue every 30 seconds. How can I make it work on-demand rather than constantly checking?

Here it is reworded slightly different:

  1. User is in .NET application and selects items then clicks Process.

  2. .Net application adds items that need to be processed to queue (msmq).

  3. An additional application will be told by the .NET application that the process button was clicked and that it should start processing the queue. Once the queue is processed the additional application should go back to some sort of idle mode.

The most important thing here is that I do not want it on a timer that checks if there is items in the queue every minute. This will eat up resources running 24/7.

Maybe I am unfamiliar with certain features of msmq. Is there a way msmq can tell my service that it recieved messages in the queue, go ahead and process them. Rather than my .net application talking to the service?

William Venice
  • 329
  • 2
  • 7
  • 16
  • 2
    If processing the queue only ever happens on-demand, why does there need to be a second application at all, instead of just an asynchronous call from your main web app? If you're set on it being a second application, probably a Windows Service would be better than a WCF or MVC WebAPI service, because a native Windows Service would generally be faster with less overhead. But there's nothing stopping you from putting your logic in a WCF or MVC WebAPI service method. – Jim Sep 17 '15 at 19:34
  • Hmm, this definitely came to mind, but I have been told running asynchronously with IIS if the process fails all of IIS shuts down so I wanted to keep it separate. I currently have a windows service but it is set to check the msmq queue every 30 seconds. How can I make it so its on button click of my .NET app or on-demand in some other way. Is this possible? If not On button click, then whenever an item gets added to the queue. The reason I was thinking Wep API or Web Service over Windows Service because my .net application can talk to those easier. – William Venice Sep 17 '15 at 19:41
  • 1
    You can create a Windows Service that has callable public methods. You write a ProcessQueue method and you call it from your web app, asynchronously without waiting for it to finish. When you say by the way that "all of IIS shuts down" if an asynchronous method call fails is not true. If you have an unhandled exception in a spawned thread (which you should always avoid by having a catch-all try/catch), it will kill your worker thread, but on the next request that worker thread will be recreated. – Jim Sep 17 '15 at 19:45
  • Hmm alright great! thanks for the info, I will think again about just simply doing it directly from the web app since it seems like the right thing to do in this scenario. Otherwise, I will stick to the Windows Service and look into creating a public method that can be called from my .NET application. – William Venice Sep 17 '15 at 19:46
  • if it's service broker (ms sql), they have the activation proc which is invoked once it's processed.. still not sure why u need another dedicated app to do that.. – g2000 Sep 17 '15 at 19:46
  • FYI - also you can host a WCF service inside of a Windows Service, and use Named Pipes or TCP bindings, which are much faster and more secure for internal communications than using http on IIS. That's probably the preferred way to do it if you want a Windows Service where you can call a method that processes your queue. – Jim Sep 17 '15 at 19:49
  • 3
    Why do you need a service at all? An executable not running is the same as a service 'sitting idle'. Spawn the executable. When if finishes the queue it exits. It's a lot easier to write, test and debug. – Steve Wellens Sep 17 '15 at 19:55
  • @SteveWellens I was thinking about doing this. Could I run the console application from my asp.net Web App? – William Venice Sep 17 '15 at 20:07
  • @WilliamVenice - Yes, I tried it and it works. At least on my local machine. You may need to to set UserName and Password on the `StartInfo` object to give it the correct rights. In any event, it's better to get your code working solidly first in a console app. You can always move it to another package if you need to. – Steve Wellens Sep 17 '15 at 22:34

1 Answers1

1

You can use your existing Windows Service. But instead of checking the queue every 30 seconds or so, why not add a listener to the queue that responds only when a message has arrived. Please check snippet below.

static void Main(string[] args)
{
    //create an event
    MessageQueue msmq = new MessageQueue("queuename");
    //subscribe to the event
    msmq.ReceiveCompleted += msmq_ReceiveCompleted;
    //start listening
    msmq.BeginReceive();
}

//this will be fired everytime a message is received
static void msmq_ReceiveCompleted(object sender, ReceiveCompletedEventArgs e)
{
    //get the MessageQueue that we used 
    MessageQueue msmq = sender as MessageQueue;

    //read the message
    //and process it
    Message msg = msmq.EndReceive(e.AsyncResult);

    //because this method is only fired once everytime
    //a message is sent to the queue
    //we have to start listening again            
    msmq.BeginReceive();
}
Ronald Ramos
  • 5,200
  • 2
  • 15
  • 12