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
Related
I know that creating a Windows Service allow us to run background jobs without having to login to the machine. while .exe files can be run when users login to their PC and click on the .exe file (require user to be login).
But now let say i create a .exe file and i schedule it to run using windows Task Scheduler. where i can specify to run the task even when the user is not login.. so in this case what will be the real difference between :-
Having a .exe which is scheduled to run using task scheduler?
and between having a windows service ?
Thanks
Task Scheduler is generally suitable for processes which carry out periodic or occasional tasks, anything from once per minute, to "at logon" or "once per year". They can be made to effectively run continuously too, but that's really an abuse of the system.
Task Scheduler can also run processes in the context of the logged-on user, and such processes can interact with the user.
Services are generally suitable for processes which run continuously, such as those servicing devices, or providing network services.
Services generally cannot interact directly with the user. Where they need to do this, there is generally a user program which communicates with the service via some sort of RPC, such as DCOM, MSRPC or something else.
There isn't really anything a service can do which a program started by Task Scheduler cannot, or vice-versa: These capabilities depend on the login identity that the program runs under, not on how they are started.
Summary:
If you want a continuous process which provides services to the network, you probably want a service.
If the process is slow to start up, but cheap to keep going once running, you probably want a service.
If you want to perform periodic tasks of any kind, you probably want a scheduled task.
If the process is expensive or intensive in CPU or disk usage, you probably want to rewrite it so that it isn't.
As long as your software do whatever it has to do correctly, there will not be any differences. It all depends in what approach you want to give to your development. I usually try to involve the less components I can in this kind of solution just to make easier the troubleshooting and manteinance. For example If you install your .exe and configure it as a scheduled task, whenever it fails you will have to check not only what is inherent to your software but all what is involved in a scheduled task (user, schedules, triggers, services), and you not always will be able to control that, as your application may be installed on a server you do not have full rights to do what you want.
Also, take in consideration that every scheduled task depends on the Task Scheduler which is a service himself.
So to resume: The advanteges of creating a Job IMHO, is avoiding to recreate all the scheduled-triggered logic that might be a headache to develop if you have not done it before. And it is not better to reinvent the wheel. In the other hand, if you have some clear task that can be done with a Timer then it will probably be a better option just to create a Windows Service.
I would like to add here that windows service (schedule tasks) deployment is in developers hand. A developer can write a code to do change the process execution time at any point of time.
At other hand process run through "task scheduler " are dependent to the server admin. Developer has to guide the admin about what time scheduler must run. If there is any requirement to run the process at some irregular time, they have to approach to server admin, either to run the .EXE manually for now and also change the scheduler time. In other case admin only need to restart the service, he will not have any concern about the time!!!
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 have a Windows service that is calling a stored proc over and over (in an infinite loop).
The code looks like this:
while(1)
{
callStoredProc();
doSomethingWithResults();
}
However, how there might be cases where the loop gets stuck with no response, but the service is still technically running.
I imagine there are tools to monitor the health of a service, to let operations teams know to restart it.
But for my scenario this won't help since the service will still be technically running, but it's stuck and can't continue.
What's the best way to ensure this process restarts if this scenario happens?
Would the solution be to use a task scheduler that checks for the heartbeat of this process, and restarts the service if it there's no heartbeat for a period of time? To have another separate thread that monitors the progress of the first process?
Windows services have various recovery options which takes care of question 1. For question 2, the best bet would be to use a timeout approach whereby if the service takes more than X amount of time to complete it restarts or stops what it's doing (I don't know the nature of your service so can't provide implementation detail).
The heartbeat idea would work as well, however, that just becomes another thing to manage/maintain & install.
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.
Folks,
I want to develop a long running windows service (it should be working without problems for months), and I wonder what is the better option here:
Use a while(true) loop in the OnStop method
Use a timer to tick each n seconds and trigger my code
Any other options ?
Thanks
Essam
I wouldn't do #1.
I'd either do #2, or I'd spin off a separate thread during OnStart that does the actual work.
Anything but #1
The services manager (or the user, if he's the one activating the controls) expects OnStart() and OnStop() to return in a timely fashion.
The way it's usually done is to start your own thread that keeps things running and ofcourse, listens to an event that might tell it to stop.
Might be worth considering a scheduled task with a short interval. Saves writing a lot of plumbing code and dealing with the peculiarities of Windows Services timers.
Don't mess with the service controller code. If the service wants to stop, you will only make matters worse by using #1. And BTW the service can always crash, in which case your while(true) won't help you a thing.
If you really want to have a "running windows service (it should be working without problems for months)", you'd better make sure your own code is properly and thoroughly tested using unit and integration tests before your run it as a service.
I would NOT recommend #1.
What I’ve done in the past for the exact same scenario/situation is create a scheduled task that runs ever N seconds, kicks off a small script that simply does these 2 things: #1 checks for “IsAlreadyRunning” flag (which is read from the database) #2 If the flag is true, then the script immediately stops end exits. If the flag is false, the script kicks off a separate process (exe) in a new thread (which utilizes a service to perform a task that can be either very short or sometimes really long, depending on the amount of records to process). This process of course sets and resets the IsAlreadyRunning flag to ensure threads do not kick off actions that overlap. I have a service that's been running for years now with this approach and I never had any problems with it. My main process utilizes a web service and bunch of other things to perform some heavy backup operations.
The System.Threading.Timer class would seem appropiate for this sort of usage.
Is it doing a
1 clean up task, or
2 waking up and looking to see if needs to run a task
If it is something like #2, then using MSMQ would be more appropriate. With MSMQ task would get done almost immediately.