Our webserver generates a file on the fly for download. This takes about two minutes of heavy processing because it's taking 1000 word templates, mail merging them, converting them to pdf, then making a zip out of those 1000 files. The processing is freezing the web server from being able to do anything else in the mean time which is a problem since it's hosting 23 subdomains for clients and they noticed it freezing.
How can i force the UI thread to get some work done? I've been looking at Thread.Sleep and Thread.Yield but perhaps i'm not implementing them correctly. I'm very new to the concept of threading.
When starting the processing on the web server, generate a "job ID" and store it somewhere (such as a database). Add an endpoint so the client can query the status of the job. When the processing is complete, the user can use the job ID to get the resulting file(s). It works like this:
User wants to process files. They call the start endpoint, which returns a JobId.
The server begins processing that job in a non-request thread, or the job is picked up and processed by another server dedicated to that task. When the thread completes, it updates the job's status accordingly.
Later...
User wants to know the status of their process. They call the status endpoint using their JobId periodically. The server replies with some status information to show the user.
Later...
Once the job's status has changed to 'complete', the user can call the result endpoint with their JobId to get the final file(s).
The heavy processing should be done in a non-UI, non-request thread so other users are unaffected.
Using this approach, you can even do the processing on another server entirely. All the web server is doing is allowing the user to create and query processing jobs.
Related
I'm making an MVC app with the .NET Framework and in one of my controllers I call an async task that sends an e-mail to the signed in user.
This task is called upon when the user clicks a specific checkbox and the e-mail is meant to work as sort of reminder.
The entire task works as intended (the user gets an e-mail when the checkbox is checked), but I need it to wait 24 hours before actually sending the e-mail, as it is a reminder.
Currently the e-mail is sent right away, how can I delay the completion of my "e-mail task", while the code continues?
Use a library like Hangfire which lets you schedule background jobs and backs them with persistent storage.
You can then easily schedule a job like:
BackgroundJob.Schedule(
() => SendEmail("user#domain"),
TimeSpan.FromDays(1));
This is a classic X Y Problem. While it may be possible to make your system wait 24 hours you are creating a very fragile system that can be affected by app pool resets and server reboots.
Putting aside the possibility of an unexpected reboot, what happens when your maintenance cycle comes around and a scheduled reboot is going to happen? How many queued email reminders will you have that you can't do anything with?
The best approach for systems that don't immediately use their data is to buffer it through some form of storage scheme. It could be as simple as writing queued emails to files on the system, or something more robust like a database with a dedicated email sending service.
I have used a LOT of email sending systems over the years, and even for immediate sends we have used a database intermediary, with one dedicated email sending Windows service to produce and send the actual email. By centralizing the email production you not only get one place to maintain your email sending code, but you can also increase the durability of the whole system.
Bonus points if your database is part of a high availability cluster, as in this kind of system the database becomes the critical point. If it is then you're protected from any form of downtime other than a total network outage.
Let the Task wait for 24 hours before sending the mail.
await Task.delay(TimeSpan.FromHours(24));
Add this line in your async function bfore sending the email
Ok. I'm calling an external script [Edit: web service] that's doing an asynchronous task. It usually takes one to two minutes to complete.
In the meantime i want to display to the user the "please wait" message, since i need to make another call to check if the previous task has been completed yet before i continue.
Using timers is not exactly a good solution. I need the user to actually wait before i continue.
So the question i have is whether or not thread.sleep will put the entire web application to sleep or just the one for the current UI?
I don't want the UI for other website visitors to hang.
I'm not sure how this works in the production environment.
I use iis 7 on windows 2008 r2
Thanks
Thread.Sleep will only affect the current thread - but it's not what you want to do anyway.
You should return a complete response from your web application - but one which starts a Javascript timer to fire in a few seconds, and then make an AJAX call back to your web app to check whether the task has completed. (You should include some sort of "task ID" in your response so that the server knows which task to check.)
If you just sleep before returning the response, your user won't see any message until the sleeping has completed.
More info would be nice. However:
I guess you are going to make a website (asp.net mvc or webforms) since you are using iis7. Just run the server and let the client use a Ajax call to ask status of the task. The task when finished should be stored somewhere, preferably a database. You can also use xml or whatever to have a point where you can then save the taskid and or it is completed or not. And just let the ajax do a call every 5 sec until it returned at the taskid true on completed.
You shouldn't use Thread.Sleep. Assuming this is a web application...
One request should start the task and return a job token.
With another request, the user should be able to check the status of that job (by passing the token).
When the job is complete, the user should be able to get the result of the job (by passing the token).
I have a application that will allow a user to upload a file. After the upload is complete there are a number of processing steps that must be done on the server (decompression, storage, validation, etc ...) thus the user will be informed sometime later by email when everything is complete.
I have seen a number of examples where the BackGroundWorker from System.ComponentModel is used to allow asynchronous work to be done in another thread. However, it seems like they lead to the user eventually getting a response. In our case no web response is necessary - the code can take up to 30 minutes to complete.
Is there another way to start a completely separate thread/process that will keep running even after the user completely closes their session?
If there is no need to respond immediately, you want to offload to some other process to do the heavy lifting. I would dump it in a DB, folder or post to a Message Queue. The worker processes (Windows Services?) would process the files, reading from the db, file system or queue. When the work is done, your worker process can call out to your ASP app (webhook style) if it needs to know when it's done. Just a suggestion.
Write a Windows Service that will run on the ASP.NET server. Architect it in such a way that it can accept and queue job requests. The queue will allow you to create the optimal number of threads in a ThreadPool for executing a subset of the queued jobs concurrently. Submit jobs to the Windows Service using either .NET Remoting, or WCF.
If processing can take up to 30 minutes, I'd recommend skipping using a background thread from the the web worker process and using something like a Windows service instead, or running a console application on a schedule using the Windows scheduler.
Once the file is uploaded, you would add it to a queue of some sort (either in a database, or using a message queuing system like RabbitMQ if you're feeling adventurous). Your web request could then return immediately and let the user know that the file is being processed, and the background service would pick the item up off the queue and continue the processing, emailing the user when it is complete.
I have a webpage with a button that generates some files to a server path. (It takes somewhere from 5 to 20 minutes). I want to create an async task that will continue executing even after the user closes the browser. Is it possible to do this with asp.net 4 and C#?
You do not control the thread pool in an asp.net application. You cannot even guarantee that a request will be completed on the same thread that it started with. Creating threads uses the same application pool that the web server uses, and you can use up all the request threads leaving your web server unavailable to process requests.
You should implement a windows service that hosts a WCF service that you can call from within your web application. In the service you can then fire off a thread to process the long running process. At the end of that process you can then update a status flag (e.g from Processing to Complete) that the user can view to determine if the files are done processing.
I would recommend using Topshelf to implement your windows service, it will save you much headache.
Actually, it is recommended that you not do this. Instead, the recommended way is to create a service (e.g. a windows service) that performs your processing asynchronously. In your web application, you create methods that starts the process, and another method that polls the service to determine if processing has completed.
There are a number of reasons for this, but one of the biggest is that the default and recommended configuration for webservers allows the server to kill long-running requests.
Or that I didn't understand what you want to do, or that you don't need to do a thing.
After the request was sent, the request process continues no matter if the user browser was closed or not. You don't need to do a thing
Fabulous nature of stateless WEB applications...
Creating new thread / using thread pool is the easiest approach to create run away tasks.
Note that there is no guarantees that process will stay alive for duration of a long task - so be prepared to handle partial completion and manual restarts. I.e. AppPoll recycle due to config change.
Easiest way is to put your task on the ThreadPool. The thread pool threads will stay alive even after the web page has completed rendering. The code would look like the following:
/* Beginning Method */
object someData = new object();
ThreadPool.QueueUserWorkItem(new WaitCallback(ProcessAsync), someData);
/* Ending Method */
static void ProcessAsync(Object stateInfo)
{
string dataToString = stateInfo.ToString();
}
you have to create a thread that does the long running task
have a look at the below:
http://kiranpatils.wordpress.com/2010/01/01/performing-a-long-running-task-with-asp-net/
Anyway what ever you start on the server it will continue running even if the user close the browser(until you recycle the app-pool or restart the web server).
I am developing an Application where I am submitting POST Requests to a .NET Web Service.
Current implementation is to process the request instantly and give response. In actual deployment, there will be huge amount of data that needs to be processed and thus the request must be processed offline.
What are the strategies that can have the task accomplished
Should I implement a Windows Service, or a scheduled task that invokes an application to perform the desired task.
This might be a good case for MSMQ. Your webservice can fill the queue with incoming data, and another process can read those messages and perform the necessary processing.
Here's a good overview of MSMQ:
http://www.primaryobjects.com/CMS/Article77.aspx
If you have so much data it cannot be processed in real-time, I would probably setup the service to do the following:
ProcessRecordViaPost
Create new record in "Queue" database with UniqueID, and all other info to be processed
Return UniqueID to client immediatly
ReadRecordViaGet
Check queue, if processed return data if not return status code (number of items in queue before it?)
I would also have a windows service that continually grabs the oldest item from the Queue, and processes it and moves on to the next oldest.