Take the 2-minute tour ×

I am building a WCF service that will expose several operations, it will run in IIS because it needs HTTPS endpoints. Most of the operations will perform within seconds or less; however, one or two of these operations will take between 5-90 minutes.

The primary consumer of this service will be an ASP.NET MVC application; what is the correct way to do handle this?

Should I jackup the timeout and do some ajax calls? Should I add a table to my database, and have the long running operations update this database, and have the web interface poll this table every minute? I'm not sure what (if there is) the generally accepted best practice for this.

share|improve this question
If the long running operations aren't transferring data, then maybe you should break this up into an async processor. So the client would request that the job be started, then check back at regular intervals to get either the response or a message saying check back later. –  Noah Jun 18 '12 at 17:25
@Noah, the long running operations are not returning much data, until they are complete, where they return about a 50kb message. –  Nate Jun 18 '12 at 18:20
You definitely shouldn't keep an http connection open for that long if your not transferring data, so it's probably best to break it up. @Jim provides a decent example. –  Noah Jun 18 '12 at 18:24
add comment

2 Answers

up vote 1 down vote accepted

I wrote something similar for my senior project, basically a job scheduling framework.

  1. I chose to go down the path of storing the "status" of the "job" in the database.
  2. I wrote a manager windows service that implemented a WCF client (proxy)
  3. I wrote a WCF Service that implemented my "worker host".

The manager service would read the queue from the database, and hand out work to all of my "worker hosts". The reason I had windows service perform this task as opposed to just having the UI talk directly to the worker host, was because it gave an extra level of control over the whole process.

I didn't like the idea of having "the network cable unplugged" from my worker host, and never getting a status update again from this specific job. So, the windows service gives me the ability to constantly monitor the progress of the WCF worker host, and if a connection error ever occurs (or something else unexpected), I can update the status to failed. Thus, no orphaned jobs.

share|improve this answer
Is there a reason you rolled your own manager instead of using MSMQ? –  Nate Jun 18 '12 at 18:32
Not particularly. I've never used MSMQ, and as I said this was just a project for school/COOP. I'm sure there are plenty of ways of improving upon the design, but it was simple enough for what I needed. The main purpose of the application was to get a handle on WCF, and although MSMQ would have been useful it wasn't the focus. –  Jim Jun 18 '12 at 18:44
In your design, do each of your "worker hosts" query the manager looking for work? Or does the manager call each work when it needs to? –  Nate Jun 18 '12 at 18:49
The "worker hosts" are just dumb workers. They have a set of implementations that get called depending on what service call they receive. They do not initiate any communication with anything else. They only respond with status updates when the manager polls for an update, etc... –  Jim Jun 18 '12 at 20:14
add comment

Take a look at this

WCF Long Running Operations There could be other options but they are nearly the same. You can also come up with some push notifications (I assume no data is returned) as one int the following link

WCF Push

share|improve this answer
add comment

Your Answer


