I have many tasks (recorded in a database with scheduled time) that need to be run on different times on different dates randomly, and each task will take a long time to process.
Every week there will be new more tasks coming up. What is the best solution to automatically execute all these tasks at an exact time?
Using an ASP.NET application to execute recurring background tasks is usually a bad idea as Phil Haack explained in his blog post.
So you could write a console application that will query your database and perform the necessary tasks. Then simply use the Windows Scheduler to execute this application at the required intervals. As an alternative you could implement the task in your ASP.NET application and have the console application simply fire an HTTP Request to the corresponding controller action.
If you don't have access to your server and cannot host anything else than an ASP.NET application then you should be perfectly aware of the consequences of going with this approach (as explained in the aforementioned article). So one approach would be to use a library such as Quartz.NET to schedule the execution of some code at regular intervals.
Related
I am using c sharp in .NET framework and want to create a scheduled task that runs every day at the same time to check all items in a specified file are due to expire. If they are due to expire the algorithm will send an alert. I have read up on windows task scheduler and was wondering if this is something I could use in this instance or if there is another scheduling instance I could use?
I've seen code that runs an executable program with task scheduler but I haven't seen any that run a particular function.
Any help is appreciated
If your goal is to schedule the task in the C# application itself you could use a framework like Quartz. But this means your application must run all the time. Maybe creating a Windows service would be a good option for that.
If your application should be called by a scheduler I would give the Windows Task Scheudler a try and see if it fullfils all your requirements. Here is a good start on how to use it: https://www.technipages.com/scheduled-task-windows
If you need multiple different task that are all embeded in the same application, I would go with the command line approach suggested by John. For that you could use the Command Line Parser Library or something similar.
I have a fairly long-running process (several minutes) that I need to run roughly once a month - but not on a fixed schedule, but after a user clicks Go in a ASP.NET Webforms GUI page.
Since ASP.NET really isn't designed to handle long-running background tasks, my idea was to put this into a separate console app. But how to launch that as needed?
What happens if I use Process.Start(....) from my ASP.NET page's code-behind? I would like to avoid blocking the whole Web UI for 20 minutes or so... and also: even if it doesn't block my UI, what happens to my long-running task if the ASP.NET app pool recycles while it's still running?
Another idea was to have a frequently running job (runs every 2 minutes) check for some kind of a flag (e.g. existence of some database entries), and if needed, that job would then launch the long-running task.
But the same question: if I launch my 20-minute task from a job using Process.Start() - does that block the caller?
It seems like a bit of overkill to schedule that long running tasks five times a day since it typically is run only once a month - but at the same time, the user expects to have his results within a reasonable amount of time (less than 1 hour, if ever possible) after scheduling the process - so I cannot really just schedule it to run once at night either ...
Hangfire is what you are looking for. Best part is it comes with a built in dashboard.
You might have to write some logic on the top of it.
You can find it here.
http://hangfire.io/
First off - for several reasons - ASP.NET is imho not the solution for long-running tasks/jobs/... whatsoever.
I have had this requirement a lot of times, and always solved/separated it like:
Worker
A service with
Quartz.net (for scheduling and processing, even if you don't have a specific timestamp for execution - but the overall handling in this framework is simply superb)
a persistent job-store (to handle start/stop and completed/aborted/paused jobs)
eg ServiceStack as the interop between the two processes
Website
Simply calls some webservice-methods of the worker to enqueue/query/pause/stop/... a job. For querying jobs a call to a unified job-store might be an option (eg. db)
It might be a bit of an overkill for you though ... but this is my Swiss army knife for such scenarios.
Use the standard built-in Windows Task Scheduler like you have done, but invoke it from your web application.
Configure your task in Task Scheduler. It does not need to have a scheduled trigger. From your web application, just use Process.Start to kick it off:
SchTasks.exe /Run /TN Folder\Taskname
I have not used SchTasks.exe directly, but have used the Microsoft.Win32.TaskScheduler wrapper classes.
This program is used for taking data that has been imported and exported it line by line to normalized tables. It can take hours sometimes.
How it works is
Uses presses button to begin processing
A call is made from jquery to a method on the MVC controller.
That controller calls a DLL which then begins the long processing
Only one person uses this program at a time.
We are worried about it tying up a ASP.NET IIS thread. Would this be more efficient if instead of the web site running the code we could make a scheduled task that runs a EXE every 30 minutes to check and process the code..
EDIT 1: After talking to a coworker the work around we will do for now is simply remove the button from the web site that processes and instead refactor that processing into a scheduled task that runs every 5 minutes ... if there are any comments about this let me know.
The question is really about the differences between the web site running code vs. a completely separate EXE...IIS threads vs. processes... Does it help any ?
If the processing takes hours, it should definitely be in a separate process, not just a separate thread. You complicate thread locking and management, garbage collection and other things by dropping this into a separate process. For example, if your web server needs to be rebooted, your separate process can continue running without being affected. With a little work, you could even spin up this process on a separate server if you want (of course you would need to change the process start mechanism to do this)
When the task can run for hours having it block an ASP.Net thread is definitely the wrong thing to do. A web call should complete in a reasonable amount of time (seconds ideally, minutes at worst). Tasks which take considerably longer than that can be initiated from a web request but definitely shouldn't block the entire execution.
I think there are a couple of possible paths forward
If this is a task that does need to be executed on a semi-regular basis then factor it into an EXE and schedule the task to run at the correct interval
If this task should run on demand then factor it out into an EXE and have the web request kick off the EXE but not wait for its completion
Another possibility is to factor it out into a long running server process. Then use remoting or WCF to communicate between asp.net and the process
I've got a windows service with only two methods - one private method DoWork(), and an exposed method which calls DoWork method. I want to achieve the following:
Windows service runs DoWork() method every 6 hours
An external program can also invoke the exposed method which calls DoWork() method. If the service is already running that method called from the service, DoWork() will again be invoked after the current method ends.
What's the best approach to this problem? Thanks!
An alternative approach would be to make use of a console application which can be scheduled by Windows task scheduler to run every 6 hours. In that case you don't waste resources to keep the Windows service running the entire time but only consume resources when needed.
For your second question: when you take the console app approach you can have it called by making use of Process.Start for example.
If the purpose of your application is only to run a specific task every six hours, you might be better off creating a command line application and creating a scheduled task that Windows runs automatically. Obviously, you could then manually start this application.
If you're still convinced you need a service (and honestly, from what I've seen so far, it sounds like you don't), you should look into using a Timer, but choose your timer carefully and read this article to get a better understanding of the timers built into .NET (Hint: Pay close attention to System.Timers.Timer).
To prevent reentry if another method tries to call DoWork() while the process is in the middle of performing its operation, look into using either a Mutex or a Semaphore.
there are benefits and drawbacks either way. my inclination with those options is to choose the windows service because it makes your deployment easier. scheduling things with the windows task scheduler is scriptable and can be automated for deployment to a new machine/environment, but it's still a little more nonstandard than just deploying and installing a windows service. you also need to make sure with task scheduler it is running under an account that can make the webservice call and that you aren't going to have problems with passwords expiring and your scheduled tasks suddenly not running. with a windows service, though, you need to have some sort of checking in place to make sure it is always running and that if it restarts that you don't lose hte state that lets it know when it should run next.
another option you could consider is using nservicebus sagas. sagas are really intended for more than just scheduling tasks (they persist state for workflow type processes that last for more than the duration of a single request/message), but they have a nice way of handling periodic or time-based processes (which is a big part of long running workflows). in that a saga can request that it get back a message from a timeout manager at a time it requests. using nservicebus is a bigger architectural question and probably well beyond the scope of what you are asking here, but sagas have become how i think about periodic processes and it comes with the added benefit of being able to manage some persistent state for your process (which may or may not be a concern) and gives you a reason to think about some architectural questions that perhaps you haven't considered before.
you can create a console application for your purpose. You can schedule the application to run every 6 hours. The console will have a default method called on application start. you can call your routine from this method. Hope this helps!!
I'm trying to find a very easy easy way to start a simple cron job for my Web Application. What I was thinking about is starting a Task in the Application_Start event. This task will have a while loop and do some action every hour or so like a normal cron job would do.
Is this a good idea or will this give some trouble?
Some of the problems I could think of are the following:
The Task suddenly stops working or hangs. Maybe make some fail over
mechanism that would check if the task is still running and if not
restart it.
Memory leaking if the Task totally goes wrong and I have to restart
the whole application.
No control in changing the Task on the fly but this shouldn't be a
problem for the thing I want to do but for others it might be.
Does someone have any suggestions or experiences with trying this?
Although Darin says that doing cron jobs in a web application is a bad idea (and I agree with him in some way), it may be not so bad, when used wisely and for short running jobs.
Using same Quartz.NET in web application may be quite nice, I'm using in one of my projects like this
http://bugsquash.blogspot.com/2010/06/embeddable-quartznet-web-consoles.html for small jobs and it is running nice - it's easy to monitor (easier than monitoring remote windows process), may be used on shared hosting.
Doing cron jobs in a web application is a bad idea. IIS could recycle the application at any time and your job will stop. I would recommend you performing this in a separate windows service. You could take a look at Quartz.NET. Another possibility is a console application which does the job and which is scheduled within the Windows Scheduler.