I have a web application and I need a specific process to run in background (all the time) and update the DB from time to time. What's the best way to do it? Create a controller with a method and run it in a thread in background? Any other option?
Your best bet is to create a separate application which you can run as a Windows Service or, if it's only a periodic update, a Scheduled Task.
The benefit of using a Scheduled Task is that you don't have to write the scheduler code - it's all handled for you by the operating system. Your application just consists of the code needed to update the database.
By divorcing it completely from your web application, it makes it more secure and easier to maintain (you can update either the web application or service independently of each other).
Related
I've been building a web service to synchronize data between SalesForce and Zendesk at my company. In the process of doing so, I've built several optimizations to drastically reduce execution time, such as caching some of the larger datasets that are retrieved from each service.
However, this comes at a price. When caching the data, it can upwards to 3-5 minutes to download everything through SalesForce and Zendesk's APIs.
To combat this, I was thinking of having a background worker that automatically cached all the required data every day a midnight. However, I'm not sure what the best method of doing this would be.
Would it suffice to build a class that merely has a worker thread that checks every several minutes to see if it is after midnight, and activate it on launch from Global.asax. Or is there some sort of scheduler already in existence?
EDIT
There seems to be some division between using something like:
FluentScheduler or Quartz.net to house everything within my applications.
Versus using something like windows task scheduler and writing a secondary application to call a function of my application to do so. It seems that using a third party library would be more simple, but is there any inherent benefit to using the Windows Task Scheduler.
I think you want to add your data caching logic to a project of type "console application". You'll be able to deploy this to your server and run it as a scheduled task using windows "Task Scheduler". If you've not worked with this project type or scheduled tasks before there are stack overflow questions which should help here, here, and here. You can add command line parameters if you need and you should have a look at adding a mutex so that only one instance of your code will ever run at once.
add an endpoint that will know how do it and use the windows task scheduler to call that new caching endpoint.
I am currently trying to create an application which has a homepage. On this homepage there is a button which is going to run CPU intensive code and then display the results. As I stated in the title the application is using ASP.NET and C# not Windows Forms which some other websites I have looked at seem to suggest.
I am relatively new to C# and have not attempted this in any other programming language. I also have no code to show as I don't really know how to progress this.
It can run CPU intensive code on the server, yes. Note that this will typically block your web application from sending a response in a reasonable amount of time and the web application could appear to be frozen.
What type of CPU intensive code did you have in mind? There are many ways to handle this scenario.
By "CPU intensive" I assume you mean it will take a long time for the process to complete? In a web application anything that takes more than a few moments should be done asynchronously. In the request/response model of HTTP it's best (for a number of reasons) to respond quickly to a client making a request.
In the case of a long-running process, by "asynchronous" I do not mean using AJAX, as that's still a request/response like any other.
By "asynchronous" what I mean in this case is that you want to have a separate server-side process which handles the CPU intensive task, and the web application does nothing more than queue the task for running and check the status of the task when people look for it. Then it can report the results of the task after it's done.
So a basic overview of the architecture would be something like this:
A user in the web application clicks a button to "start the task."
The web application inserts a record into a database table indicating that the task has been queued (maybe with a user ID of who queued it, a time stamp, anything else you'll need to know).
A separate scheduled application (console application or Windows Service, most likely) is perpetually running. (Either using a timer in an always-running Windows Service or scheduled to run over and over, such as every few minutes, as a console application.) This application checks the database table for new queued tasks.
When the application sees a task, it marks it as "started" in the database (so subsequent runs of the application don't try to run the same task in parallel) and starts running it.
The web application can see the status of the task in the database table and display it to users who request it, so users can see that it's still running.
When the task is completed, the task record in the database table is updated and the result is stored somewhere. (Depending on what the result is. Data? In the database. A report file of some sort? Save as a file somewhere. That's all up to you.)
The web application can see the status of the task as completed and any other information recorded, and users can request to view the output of the task.
The main thing to remember here is to break up the responsibilities into two applications. The web application is for the purpose of providing a user interface. A web application is not suited for long-running background tasks. So that responsibility is moved to a separate application which is better suited for that purpose. The two applications coordinate via a shared database.
I am creating a web application in which I need to allow the user to schedule the excecution of a task.
I have gone through the various threads for scheduling the task but all of them are using windows service that I am not aware of. Moreover I cannot install visual studio in the server systems due to budget constraints.
Is there a way to create a method that runs a scheduler in a background thread in the asp .net application.Any code sample will be of great help.
That's not the way to go. If you need a scheduled task you should create a console application and run it using the Windows task scheduler.
You could create an application that sends an email to the user with a link to the page where the task is supposed to be done.
One thing to understand is that ASP.NET is intended to service requests from the network.
Everything in it is geared towards that. So, yes, you can run background tasks, but there are a number of caveats and gotcha's.
For instance, IIS will shut down your ASP.NET application if it does not receive any requests for some period. Also, your Application may be restarted without warning, if it detects changes to the file system. So, running code will be aborted.
That's not to say you can't work around these, but it's really not the best fit for scheduled task execution.
Your best bet would be to store the details of the task in a database, and then using either a single always-running Windows Service (really not that difficult to do, there are plenty of examples), or a console application (as suggested) scheduled manually to run regularly, to execute these tasks.
You may find that a library such as Quartz.NET may be of help scheduling/running these tasks.
I have IIS server which runs few WCF REST services I created.
Now I need to add some kind of process that will run on the server and do some work for me once in a while.
I guess the IIS should initiate some kind of a background process or something, but I'm not sure what is the technology I should use in this case?
After reading at least three other similar questions, it appears the best practice is to avoid running background threads and allow a windows service app to do the processing. You could drop rows into a database table or append a line to a file to start the windows service work.
See any of these threads...
Can I use threads to carry out long-running jobs on IIS?
What are some best practices for managing background threads in IIS?
As an alternative to Windows Task Scheduler, as mentioned by others, you could also:
In your global.asax file, in your application_start() method, you can spin up a new Thread to do whatever you want, and shut it down in the application_end() method.
Check out the window task scheduler
You can schedule a process to come to life and then check to see if any component has queued up work for it to do. The work could be stored in a file (which would need to be locked) or a database table (that's my preference).
Windows Scheduled Tasks would typically be the way to do this.
My issue is pretty simple.
I have an application that should be executed automatically once a day. I have no prior experience with this kind of scenario (some time ago I worked with IBM Control-M but guess that it is way more complete, complex and expensive =))
I thought about two possible solutions:
Creating a Task inside Windows Task Scheduler, which would execute the application;
Implement the application as a Window Service which would run 24/7, but only would perform the needed actions depending on the current time.
Which are the advantages/disadvantages of each approach?
Is there another way to do this?
Thanks in advance.
If it only executes once a day (or so) then just do it as a regular command line app that is executed by the windows task scheduler. Task scheduler already has all of the UI necessary to determine when to kick off the program, pass in parameters and anything else related to the scheduling of the task.
The only real reason to do this type of function as a windows service is if it needs higher execution resolution than once a minute. However, the main downside to a windows service is that you would have to manage the logic for how often/when to kick it off. Another one is that the app is always running, which leaves open the possibility for leaked memory if your code has issues.
On Unix/Linux you would use a cron job schedule a task to be executed. MS Windows' version is called the Task Scheduler and it is already a service that run 24/7 and performs the needed actions depending on the time.
Create a repeating task with the Task Scheduler to run your application. Creating, installing and configuring a service application is not exactly trivial. It's a much more involved process than creating a standard Forms or command line app and you don't need to do it anyway.
http://msdn.microsoft.com/en-us/magazine/cc164015.aspx
http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-csharp/70633/Waitable-Timer-in-C
Another library that might be of interest is Quartz.NET