views:

346

answers:

5

Applet needs to poll for existence of a directory, say, every 1-4 hours, and send a couple emails/NET SENDs if it is not found. Not sure on exact interval yet, but it will definitely not be shorter than 1 hour. The overall "job" will be permanent and continuously-running for the foreseeable future. Applet will be running on a Win2k3 Server, and based on (extremely light) user usage patterns, I doubt it will interfere in any noticeable way with primary server functions, but just want it to be well-behaved, of course! Considered implementing it as a Win Service eventually, but for various reasons, first implementation will be as a console app.

Seeking the implementation that will be leanest in terms of system resource use, specifically CPU and RAM. Concerned most about the timing/polling implementation vs. CPU usage. There will not be a ton of objects, GUI, etc. created, so RAM usage should not be much of an issue, but do I need to give special consideration to Garbage Collection if I do implement it as a long-running .exe (in the months/years sense)?

FileSystemWatcher?
System.Timers.Timer?
Thread.Sleep?
other?

Actually, as I write this, it occurs that the simplest implementation -- from the standpoint of reusing the many existing "wheels" already invented for this type of task -- will be to not poll at all, but simply design it to start, perform actions, and close, and let Windows Scheduled Tasks infrastructure handle the timing aspect. But I posted anyway to get validation of that idea + general info for future reference. TY!

+1  A: 

Use Windows Scheduling Services to schedule the running of your console app. Do a simple check for the directory using Directory.Exists and send emails as necessary.

Yuriy Faktorovich
+1  A: 

I'd go with designing it to run as a headless application (logging to the event log or your sink of choice) and letting the Task Scheduler do its job and call it on the hour.

No need to overcomplicate things.

48klocs
A: 

In the past I've handled tasks like that by simply creating a console application and having it execute from a Windows Scheduled Task. That way it can perform its action and then unloaded from memory. Also, it's easy to temporarily disable the scheduled task if there's work that needs to be done to the server (like system upgrades). Also, it the schedule needs to change (more/less often), the scheduled task interface already accounts for multiple runs.

Agent_9191
A: 

Windows Scheduled Task is definitely the way to go. And Thread.Sleep(n) is definitely not the way to go. A System.Timers.Timer would be the way to go if you were going to do this from within your application, with an initial interval of 3600000. In each Elapsed event, you should disable the Timer, do whatever code you need to do, then re-enable the Timer with an Interval equal to the next hour-on-the-hour minus the current system time. Otherwise your Timer will drift out of sync with the system time (although this might not matter for your purposes, in which case to hell with it).

MusiGenesis
A: 

We've tried to write similar tools as Windows Services (as you said a future implementation may be) for several reasons:

  • Simple remote administration via NET.EXE (and eventually PowerShell)
  • Easy monitoring via System Center Operations Manager (formerly MOM)
  • Can cache data/objects if needed
  • Standardization

Note that we developed a framework and associated template for creating these projects; that way each project doesn't have to handle configuration of the polling interval, etc.

TrueWill