I often find when I'm writing a service class (within an ASP.NET app) that in addition to the usual method calls, I'd like scheduled method calls which invoke, say, every day at 1am.
My idea is to create a custom attribute which would be used against any scheduled task methods:
[ScheduledTask(Every=TimeSpans.Day, At=6)]
public static void Cleanup()
{
// some clean up code here
}
In order to implement this, I would have to scan the assemblies loaded in the AppDomain at the web app's Application_Start method. Look for static methods with the ScheduledTask attribute and then invoke the scheduler to run these methods according to the attribute.
I've looked around the net and found that no-one else seems to have done this and wondered whether this is generally a bad idea for some reason!? Would it be possible do you think?
thanks!
Some problems I see:
Separation of concerns. Your class provides the Cleanup implementation and the schedule to run it. An administrator is likely to want to control the schedule (e.g. run Cleanup at times of low activity), so it's more common to use configuration to provide a schedule.
Difficult for an administrator to get an overview of what tasks are scheduled.
Interpretation of the schedule. Is your example 6 UTC or local time?
Ease of modification of the schedule - you need to recompile.
ASP.NET applications can shut down, e.g. after a period of inactivity, or on a predefined schedule, and won't start up again until another request arrives. Which makes IIS a poor host for running scheduled tasks.
Related
I am trying to run a Background Scheduled Task (in a Console App) after x minutes and I can easily achieve it using Task.Delay. But, what is the advantaged of using a Task Scheduler?
EDIT: BTW, I do not have any special requirements, just want to understand why one is better than the other. A Task Scheduler requires a lot of code, so why is worth the Scheduler Task?
This is an example that I am following: https://blog.maartenballiauw.be/post/2017/08/01/building-a-scheduled-cache-updater-in-aspnet-core-2.html
Task.Delay does what it says on the tin and thats about it.
The IScheduledTask/IHostedService implementation provides a couple of features.
You have a self contained class that can have dependencies injected to run the code in its own scope.
IHostedService provides a mechanism for graceful shutdown. In an ASP.NET application, the app can be recycled, you don't have a guarantee that the code you called Task.Delay(1000*60) on will execute. With IScheduledTask solution, you implement the StopAsync() method to provide a graceful cancellation of the Task. You can also configure the Host Configuration Shutdown Timeout.
Your question is regarding a console application and it appears from here as of .Net Core 2.1 the WebHost will be replaced with Generic Host and as such will no longer pertain specifically to ASP.NET.
Tangent: I have a related question ASP.Net Core 2.0 Shutdown Timeout, what issues can I expect using a very long time out of 2 min?
<- I have not had any issues in Production with a time out of 2 min.
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.
for a backup program I am doing I have already finished the GUI. Now I want to do the functional requirements. Each backup can have schedules. There are predefined settings like every Sunday or Monday but the user can also specify his own schedules.
As I have never done anything like this, I was wondering what a good approach would be to running a backup every x hours or days. I was thinking about using Threads or writing a service but both fields are totally new to me. What would be the best method here?
If threaded development and service development are both totally new then I think you will struggle to implement this in a useful way. Even so...
Scheduler-type applications are best run as services, because otherwise you need the user to be logged in to be running the application. Services run independently of the user being logged in.
Because of this, however, services don't have a user interface so your GUI needs to package up the details of schedule into a configuration file somewhere, then signal the service to re-load that configuration file so that the service will then know what to do and when to do it.
The service will normally spawn a worker thread to do pretty much everything, and that worker thread needs to be able to respond to the service being shut down (read up on AutoResetEvent to see how this might be done across threads). The thread will then wait until either an event or for the appropriate time to arrive and then do whatever it has to do.
None of this is actually complicated, but I suggest you do some digging into multithreaded programming first.
I agree with ColinM, Services are best for the Scheduler Type of application.
You have to combine the Services with application to run your code at scheduled intervals.
See the article for more details - http://msdn.microsoft.com/en-us/magazine/cc163821.aspx
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
Let me explain the scenario and what I am trying to accomplish.
Scenario:
I have a web application that collects a date (ex 07/12/2011) and a time (ex 07:45PM) and store them into database (SQL).
What I am trying to do:
At 07:45PM on 07/12/2011, I want to call a web service to run another job.
I am thinking about building a windows service that runs every 15 minutes everyday, gathers all the "pending" requests (dates and times), queues them up, and executes the requests in that order.
Please feel free to provide any other approach for this.
In the past when I have done this I use the Windows Task Scheduler to run the exe that does what I want.
For what you are wanting to do a windows service seems like overkillm, I typically just create a basic console app that does what I need. With the Task Scheduler you can specify exactly when you want to run it and you are done.
Windows Services add a (sometimes) unnecessary level of complexity to a problem like this.
I would recommend starting with a simple console application and using Windows Scheduler to run it every x minutes.
If you decide to convert to a "real" service at a later time almost all of your code should be reusable.
You could evaluate the following solutions before writing out a windows service.
http://www.firedaemon.com/ - FireDeamon provides a free version for scheduling jobs.
http://quartznet.sourceforge.net/ - An open source scheduling library, good to go for if your windows service need to support more features.
If you are working on .NET Framework 4, this link should shed some light on this issue.
I've used Quartz.Net with some success. It's a bit more flexible than you've described. Scheduling a new task is as easy as:
public static void Schedule(DateTime when, string applicationId)
{
ISchedulerFactory factory = new StdSchedulerFactory();
IScheduler scheduler = factory.GetScheduler();
JobDetail jobDetail = new JobDetail("Realization Job", null, typeof(CustomTask));
jobDetail.JobDataMap["applicationId"] = applicationId;
Trigger trigger = new SimpleTrigger("Custom Task Trigger", DateTime.UtcNow, null, 0, TimeSpan.Zero);
scheduler.ScheduleJob(jobDetail, trigger);
}
Note that I have a wrapper around the JobScheduler that allows it to act as a Windows service. Creating this as a Windows service allows me to have more robust error handling and does not force me to rely on the OS like the Task Scheduler does.
I've used both Windows Task Scheduler and Windows Services in different web projects, both have their merits.
Personally, I prefer using scheduled tasks. Usually, I'll have a small generic tool calling a URL in the main web application. Sort of like a web service call. The output is appended to a log file.
The benefit of this setup is that if you deploy a new version of the web application, the service is updated as well.
I'd recommend a Windows Service only if you have to perform long-running tasks or tasks that require access to unsafe resources since these don't work well with web applications.
Then again, the same sort of tasks could also be performed from a command line tool.
In practice I've found that main problem with Windows Services is the fact they run indefinitely. In a perfect world that's not a problem. In the real world however, I've seen services leaking memory (yes, .NET based services). Over time these services will start to suck up more and more resources.
A scheduled task will start a new process for each invocation, limiting the amount of damage a leaky task can do.