I have a console application which should periodically listen remote database,
if there is a new value then do some stuff.
Normally I create windows task scheduler job to run this console app every 2 minutes.
Another option I think, in console app I will have a code like;
while(true)
{
ConnectDatabaseAndProcess();
System.Threading.Thread.Sleep(120000);
}
So I assume console app will be always open, and will wait 2 minutes for every process and continue.
In performance matter will it make any difference?
Unless your computer is so overloaded that the time to create a process every two minutes is a huge drain on resources, there's no benefit to having your program sitting in a loop waiting for two minutes, just so that it can poll the database.
The benefit of using scheduled tasks is that you can change the scheduled task frequency (make it once every five minutes, or once an hour, or whatever) without having to modify the program. Sure, you could use an application configuration file, but why? Why duplicate functionality that already exists in the operating system, and is more flexible.
Also, with a scheduled task, you know that the program will start the polling operation again the next time the computer is rebooted. If you depend on the program to provide that delay, you have to either remember to start it every time, or put it in the startup task list.
Also, when the program is sitting there idle, it's occupying memory that could be used by other processes.
All told, using scheduled tasks is a much more flexible and robust solution. Any marginal performance gain (and we're talking, at most, one second) from having the program always running is far outweighed by the disadvantages.
Related
I using Azure Cloud Worker Role for processing incoming task from queues. Processing of each task can take up to several hours and each worker-role can handle up to N tasks simultaneously. Basically, it's working.
Now, you can read in documentation that from time to time, the worker role can be shutdown (for software update, OS upgrade, ...). Basically, it's fine. But, this planned shutdown cannot forcedly stop the worker-role already running tasks.
Expected:
When calling the OnStop() method by the environment:
the worker role will stop getting new tasks for processing.
Wait for running tasks completion.
Continue with the planned shutdown.
Actual:
OnStop() method can be block for up to 5 minutes. I cannot guaranty that I'll finish processing the task in 5 minutes - so, this is problem... My task is being killed in the middle of processing and this became unstable situation for my software.
How I'm can avoid this 5 minutes limit? Any tip will be welcome.
How I'm can avoid this 5 minutes limit?
Unfortunately, you can't. This is a hard limit imposed from Azure side. You will need to work around that.
There are two possible solutions I can think of and both of them would require you to rethink about your current architecture:
Break your one big task into many smaller tasks and create some kind of work flow.
Make your task idempotent so that even if it gets terminated in between (because of worker role shutdown or error in task itself) and when it gets pick up by another instance, it starts again in such a way that your output of the task is not corrupted.
No, you cannot bypass this limit. In general you should not rely on any of your instances running continuously for any long period of time. Instances may be suddenly stopped or they may suddenly disappear (because of an underlying server failure). You software should be designed such that when an instance is restarted (possibly redeployed) or some other instance finds capacity to take a previously released work item that work item is reprocessed without any adverse effects.
I'm developing a Windows Service that will run every 15 minutes, and sends out push notifications to iOS, Android, and BlackBerry users. Each of these device specific operations will run in separate threads in the Windows service. That's all well and good, but there is a chance that we will need to send out up to 50,000 push notifications at a time. If this happens, it could possibly take more than 15 minutes, so before it's time for the next service to run, I want to know if the previous process has finished, and if it hasn't, wait and queue the Windows service to execute once the prior execution is complete. I'm fine with the threading aspect, but I don't know the correct way to implement the scenario that I've described above. Is there some sort of "Wait" or "Queue" mechanism in C#?
Since your service is using a Timer to schedule the work, it can always disable the timer when work begins, and reschedule, as needed, at the end of your work.
This allows a lot of flexibility. If a queue of work took more than 15 minutes, you could decide whether to delay the next one, just start it immediately (potentially running "forever"), skip it entirely, or whatever you needed, as the timer won't run again until it was reenabled.
I would like to write an application in C# which runs in the background most of the time. It should only show a TrayIcon. For this I found a tutorial: http://www.simple-talk.com/dotnet/.net-framework/creating-tray-applications-in-.net-a-practical-guide/
But how can I tell my program to run every hour? Whats the best way to implement this. A timer? The app should use as less as possible resources while doing nothing.
thanks
Don't have a program that runs all the time but only performs activity every hour. Write a program that performs the activity and then schedule it hourly using Task Scheduler in windows.
Question: is the program you're doing a "user space" program, or should it run even if a user is not logged in? In other words, should it always be on?
Basically, are you doing something useful to a user, or is this for a business task like archiving a web server's log files to database?
If it's the former, keep doing your notification area program. If it's the latter, skip the notification area program and build a full-out Windows Service.
In both cases, use a timer; resource use will be minimal.
Not sure of the processing cost, but you could code in a sleep timer to put it to sleep for an hour in a loop so it will wake up, run, then sleep again. Not sure of the drain on resources when sleeping though. Also, if the program might take a few minutes, you could calculate sleep time based on the DateTime.Now DateTime object so it wakes up every hour on the hour.
I need to implement a windows service that performs database import, and that once a month.
The program receives data via e-mail, and will import them at the end of each month.
Is there a better way than set the program to sleep for max_integer seconds/miliseconds repeatedly ?
I would not do it as windows service. I would run it as a scheduled task.
Your service will just be sleeping for a month and is just a a waste of resources. Let the OS keep track of the time and start your application to do the once a month processing.
If you can avoid writing a window service, you'll make your life easier - scheduled tasks may be a better option here. Windows services are best used for things where there is some constant background activity that needs to happen - not for running tasks over long timescales.
However, if you must make this a windows service, then you don't want to set a long-timer sleep timeout. That's most definitely a problematic approach. What happens if your application is restarted? How will it know how long it's been sleeping for? Or what if the thread is restarted?
A better approach is to write a record somewhere in the database that identifies when the next import should happen as a date/time. You windows service can wake up periodically (every few minutes or hours) and see if the current date/time is greater than that value. If it is, run the import and update the next run date in the database to the next time to run.
If your app is restarted, you simply read the value back from the database and continue as before.
I have a task that needs to run every 30 seconds. I can do one of two things:
Write a command line app that runs the task once, waits 30 seconds, runs it again and then exits. I can schedule this task with Scheduled Tasks in Windows to run every minute
Write a Service that runs a task repeatedly while waiting 30 seconds in between each run.
Number 1 is more trivial, in my opinion and I would opt to do it this way by default. Am I wimping out? Is there a reason why I should make this a Service and not a scheduled task? What are the pros and cons of both and which would you pick in the end?
I read a nice blog post about this question recently. It goes into a lot of good reasons why you should not write a service to run a recurring job. Additionally, this question has been asked before:
https://stackoverflow.com/questions/390307/windows-service-vs-scheduled-task
Windows Service or Scheduled Task, which one do we prefer?
One advantage of using the scheduled task, is that if there is some potential risk involved with running the service such as a memory leak or hanging network connection, then the windows service can potentially hang aroung for a long time, adversely affecting other users. On the other hand, the scheduled task is written to be short running, so even if it does leak, the effect is minimised.
On the other hand, someone in one of the above questions commented that the scheduler has a limit of accuracy of somewhere in the range of 1 minute, so you may see that the scheduler is unable to run your task every 30 seconds with accuracy.
Obviously there are a number of tradeoffs to consider, but hopefully this will help you make a good decision.
If you're trying to run every 30 seconds, I'd go for option 2. This is pretty much a continually running job, in that case. The overhead of starting and stopping the process is probably higher than the process itself, especially if you use an appropriate timer.
If you make a job that is running once a day (or a few times a day), then I'd go for option 1 - using a scheduled task.
The task scheduler in windows seems a bit flakey in my opinion. I think you would get a more reliable result running as a service.
Also, a service could keep resources in memory, such as reading input from a file, and only have to do this at start-up of the service, not every 30 seconds.
30 seconds is a pretty short interval (relatively speaking) between processing cycles. Like the others I have my concerns about the task scheduler and I am afraid such a short interval will only compound the issues you might encounter if you took that approach. If this were my project I would almost certainly go with the service.