Best way to run a background task in ASP.Net web app and also get feedback?

Question

I am thinking on the following approach but not sure if its the best way out:

step1 (server side): A TaskMangaer class creates a new thread and start a task.
ste

Answer 1

One approach for doing this is to use application state. When you spawn a worker thread, pass it a request ID that you generate, and return this to the client. The client will then pass that request ID back to the server in its AJAX calls. The server will then fetch the status using the request ID from application state. (The worker thread would be updating the application state based on its status).

Answer 2

I saw an approach to a similar problem somewhere. The solution was something like:

1. Start the background task on server.Return immediately with a url to the result.
2. Until the result is posted, this url will return 404.
3. The client checks periodically for this url.
4. The client reads the results when they are finally posted.

The url will be something like http://mysite/myresults/cffc6c30-d1c2-11dd-ad8b-0800200c9a66. The best document format is probably JSON.

If feedback on progress is important, modify the document to also contain status (inprogress/finish) and progress (42 %).

Answer 3

Microsoft Message Queuing was built for scenarios like the one you try to solve: http://www.microsoft.com/windowsserver2003/technologies/msmq/default.mspx Windows Communicatio Foundation also has message queuing support. Hope this helps.

Thomas

Answer 4

I think the problem with storing the result in the cache is that ASP.NET might scavenge that cache entry for other purposes (ie if its short on memory, if its grumpy, etc). Something that is served from the cache should be something you can recreate on demand if its not found in the cache, the ASP.NET runtime is free to dump cache entries whenever it feels like it.

The usage of the cache in the badge discussion seems fundamentally different, in that case the task was shortlived. The cache was just being used as a hacky timer to fire off the task periodically.

Can you confirm this is a task that is going to take 5 minutes, and require its own thread that whole time? This is a performance concern in itself, you will only be able to support a limited number of such requests if each requires its own thread for so long. Only if thats acceptable would I let the task camp a thread for so long.

If its ok for these tasks to camp a thread, then I'd just go ahead and store the result in a dictionary global to the process. The key of the dictionary would correlate to the client request / AJAX callback series. The key should incorporate the user ID as well if security is at all important.

If you need to scale up to many users, then I think you need to break the task down into asynchronous steps, and in that case I'd probably use a DB table to store the results (again keyed per request / user).