Scheduled Task Vs. Service / Application

[Auguy]

I need some advice about running some functions through scheduled tasks on a server vs. having an application or service that would run continuously on the server but only run these functions every few minutes or so. What I have now are various scheduled tasks running every 20 minutes. These tasks all call the same vb.net application with a parameter that tells the program what to run. The time between these various tasks is approx. 2-3 minutes and range from file transfers with FTP, automatically sending email notifications, to updating SQL tables. So basically something is running every 2 to 3 minutes and the whole cycle starts over every 20 minutes. Is it better in terms of server usage, etc. to keep the scheduled tasks or write my own service or application to handle the timing internally in the program? The nice thing about the scheduled tasks is that I have them set up to end if they take more than 3 minutes to run.


Auguy
Sylvania/Toledo Ohio

 

[MrDataGuy]

What I am about to post is total I.M.O. only and based 100% on my gut.

First am I right in reading that there are several small apps running ( Lets call them A,B,C,D, ) that every so often call one common app (Lets call it X )?

If so, for me, that is completely backwards ( But that may be like saying a glass is half full, or half empty. Neither is right or wrong. Same with what you are describing here, it may be 'wrong' for me but perfectly fine in the real world. )

What I would do (again I am not saying that I am an expert and this is the one and only way to do it) is to write an app (very small app ) who job it is, is to kick off the running of other apps. Most likely it reads a small file (XML, CSV, etc. ) that contains information on what and when to run, might also log what apps it calls to run. Then I would have a number of small sub-apps each with a single responsibility, e.g one to do the FTP one for email notifications etc.

Some of the nice features of this setup:

-Only the dispatching app is running all of the time (well really 99%+ of the time it would be paused/sleep and waking up every so often to figure out if some sub-app should be started to do something as not to stress the CPU. )

-When a new app is needed (e.g. FTPing to a 2nd site etc.) then all one has to do is drop the new APP in the folder, update the small task file and either the dispatch app auto-rereads the file every so often, or you manually restarted it and away you go.

-If an sub-process is not needed to be run, just remove the app from the folder. (This assumes that the dispatch app has been programmed not to crash if the sub app is not there. )

-This way one follows the programming rule of “Each Program/Class/Method etc.” should only do one thing and do that one thing well.

-Heck if someone wrote a sub-app in Java, or C#, or… using this method it could be (easily?) adding to the system.


Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[Auguy]

Thanks, Actually there is only one app called by the different scheduled tasks with a different parameter for each task. The app looks at the parameter and determines what to do from there. I will put some serious thought into your ideas. Thanks again for your insight. Most of these functions can also be called from within the app by any of the users.


Auguy
Sylvania/Toledo Ohio

 

[MrDataGuy]

For some food for thought look at:

http://en.wikipedia.org/wiki/Single_responsibility_principle

http://www.objectmentor.com/resources/articles/srp.pdf

etc.


Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[davejam]

Like MrDataGuy, the following is purely down to my opinion due to my experiences.

I inheritted an automated system that ran the entire company using scheduled tasks, various scripts and a couple of .net applications.

This was very disjointed, badly documented and extremely unreliable (no end of, this isn't working or that isn't working.... and not knowing what was doing what!!)... also for someone walking into the job, it was seriously difficult to work out where problems were occurring!!

Also when our main server wasn't logged in some of the services that imported / created files would not run, which is completely impractical, especially when you want to take holidays without phone calls!!!

I have since re-written everything into single process vb.net applications, one process app for each stage in the process, named with what the process actually does and numbered so there is an order to how information passes through the company!!

I created each one as a service and installed as a service on the server and have had minimal problem setting up, and i haven't come across an issue apart from the odd square peg that won't fit through the round hole.... which previously would have crashed everything. (thats probably jinxed it!! but it has been running successfully since october)

Also with the advanced error handling using "try" in vb.net it is far easier to grab errors, log them, and write a simple app that displays any errors that may occur across the entire process. This make fixing any issues much easier. I've also created some small apps so our users can actually correct the problem and put it back into the process to complete... no interaction needed from IT in these simple cases!

Only problem with building services, you can't run them to debug the code, its best to create them as a windows application to debug then port the code across to the service once you're happy.

One big piece of advice on services, always install them initially as manual startup, if you've overlooked something in the code and a service hangs while starting, i found it hard to force it to stop without simply rebooting.... if the service is setup as automatic startup you're stuck with the same problem where i didn't get the option to stop the service!!! i'm sure theres a way round this but I had real problems!

daveJam

it works on my machine, so technically i win!

 

[RiverGuy]

I would keep it as a schedule task. Why reinvent the wheel?

 

[Auguy]

Thanks again to everyone for your thoughts on this matter. I'm leaning towards just leaving them as scheduled tasks because they are already set up and working fairly well. Some very interesting ideas were put forth and I will consider all of them, if not in this project, then a future one.

The one thing I want to improve is the FTP. I need to look for an FTP client or some code so I can FTP from within the program and trap errors/problems more easily.


Auguy
Sylvania/Toledo Ohio