Konzeptfrage: Aufgabe einmal am Tag ausführen

[Bbommel]

Hallo zusammen,

ich habe einen in Delphi geschriebenen Server und dieser soll einmal am Tag auf einem anderen Server prüfen, ob eine Datei vorhanden ist und diese ggf. runterladen. Mein einfacher Ansatz wäre jetzt: einen Thread erstellen, der genau diesen Job macht und sich dann wieder für einen Tag schlafen legt. Vielleicht auch etwas verfeinert, indem der Thread alle x Minuten auf einen Zeitpunkt prüft, den man für seine Ausführung festlegen kann.

Soweit wäre das alles in der Umsetzung schnell gemacht und kein Problem, aber es kommt mir irgendwie so "überflüssig" vor, wenn ich da den ganzen Tag einen Thread "rumliegen" habe, den ich eigentlich nur kurz brauche. Ist das trotzdem der einfachste und ein legitimer Weg oder gibt es irgendeinen eingebauten Scheduler oder so, den ich gerade völlig übersehe?

Ach so, bevor das jemand vorschlägt: TTimer scheidet aus - Serveranwendung ohne VCL, die auch unter Linux läuft.

[Phoenix]

Linux hat cron. Damit kann man eben sogenannte cronjobs starten, nach bestimmten Mustern. Zum Beispiel genau einmal am Tag.
Der Cronjob wird als ein commandline-Befehl hinterlegt, und Cron sorgt dann dafür, das der entsprechend dem Muster eben entsprechend oft ausgeführt wird.

Bei Windows gibt es analog dazu auch den Task Scheduler, mit dem man eben auch beliebige Programme in definierbaren Abständen ausführen kann.
Will heissen ich würde den Task der das macht, in eine eigene executable auslagern und die mittels cronjobs steuern.

[dummzeuch]

Ich würde das vermutlich auch mit einem Thread machen, den allerdings nicht per Sleep warten lassen sondern auf ein Event-Objekt. Das hat den Vorteil, dass man ihn beim Beenden des Programms einfach aufwecken kann, so dass er sich selbst beendet.

[Bbommel]

Klar, das mit dem "Schlafenlegen" war nur so dahingeschrieben. In der Praxis sieht das auch bei mir so oder so ähnlich aus:

Delphi-Quellcode:

var
  EventWait: TEvent;

[...]
procedure TecsDelOldSessionsThread.Execute;
begin
  while not Terminated do begin
    EventWait.WaitFor(60000);
    ecsSessionList.DeleteOldSessions;
  end;
end;

Funktioniert auch problemlos. Aber sicherlich gut zu erwähnen, falls mal jemand per Sucher hier landet. Bei so einem Beispiel wie dem hier, das einmal in der Minute läuft, hatte ich auch nie weiter drüber nachgedacht, nur halt jetzt bei dem Fall, der eigentlich nur einmal am Tag was machen soll, kommt mir das immer noch unpassend vor.

Zitat:

Zitat von Phoenix (Beitrag 1514743)

Will heissen ich würde den Task der das macht, in eine eigene executable auslagern und die mittels cronjobs steuern.

Danke auch dir für das Feedback! Was mir daran nicht gefällt, ist wieder ein zusätzlicher administrativer Aufwand (klar, der ist erstmal überschaubar, aber dennoch blöd, wenn man es dann z.B. mal vergisst) und eine zusätzliche Abhängigkeit zu einem zweiten Programm für eine Aufgabe, die eigentlich intern laufen könnte. Aber drüber nachgedacht hatte ich da auch schon.

Oder selber einen kleinen Scheduler bauen, weil es halt diverse Aufgaben gibt, die alle paar Minuten zu erledigen sind, da ist jetzt das eine Beispiel nur der krasse Ausreißer.

[himitsu]

Die Aufgabenplanung kann auch von deinem aktuellen Service erstellt/verwaltet werden, über welches dann deine ServiceExe mit Parameter oder eine andere EXE oder Batch gestartet würde.

Wir haben auch einen Service, welche ja eine Abeitschleife hat ... ja, dort prüfen wir für mehrere Aufgaben auch die Zeit und führen dann deren Aktionen entsprechend aus (oder nicht) ... jeweils der letzte Zeitpunkt gemerkt und dann geschaut, ob die aktuelle Zeit größer/gleich dem neuen Zeitpunkt ist.

[Der schöne Günther]

Ich habe für solche Dinge in unseren Server-Anwendungen ein paar Events wie

Delphi-Quellcode:

OnMinuteChange

,

Delphi-Quellcode:

OnHourChange

,

Delphi-Quellcode:

OnDayChange

, ...

[mytbo]

Zitat:

Zitat von Bbommel (Beitrag 1514742)

ich habe einen in Delphi geschriebenen Server und dieser soll einmal am Tag auf einem anderen Server prüfen, ob eine Datei vorhanden ist und diese ggf.

Du hast nicht erwähnt, mit welcher Library der Server erstellt wurde. Die mORMot REST-Server haben dafür einen Mechanismus implementiert. Damit reicht folgender Quelltext:

Delphi-Quellcode:

var
  timer: TRestBackgroundTimer;
begin
  timer := TimerEnable(DownloadFile, 60 * 60 * 24);
  if timer <> Nil then
    timer.ExecuteNow(DownloadFile);
end;

procedure ...DownloadFile(pmSender: TSynBackgroundTimer; const pmcMsg: RawUtf8);
var
  content: RawByteString;
begin
  content := HttpGet(URL);
  ...
end;

Man kann die Klasse TSynBackgroundTimer auch eigenständig verwenden.

Bis bald...
Thomas

[generic]

Da gab es mal im Entwickler Magazin 2013 ein Artikel der das Thema behandelt:
https://entwickler.de/programmierung/back-in-time

Du kannst u.a. auch den Windows Scheduler nutzen, da gibt es eine API zu.
Alternativ gibt es auch eine CRON Komponente für Delphi.
https://github.com/kapkapas/CromisLibrary

[jobo]

Zitat:

Zitat von Bbommel (Beitrag 1514749)

Zitat:

Zitat von Phoenix (Beitrag 1514743)

Task der das macht, in eine eigene executable auslagern und die mittels cronjobs steuern.

Danke auch dir für das Feedback! Was mir daran nicht gefällt, ist wieder ein zusätzlicher administrativer Aufwand (klar, der ist erstmals überschaubar, aber dennoch blöd, wenn man es dann z.B. mal vergisst) und eine zusätzliche Abhängigkeit zu einem zweiten Programm für eine Aufgabe, die eigentlich intern laufen könnte. Aber drüber nachgedacht hatte ich da auch schon.

Interessant, wie unterschiedlich man solche Aufgaben betrachten kann.
Anhand der Aufgabenstellung habe ich jetzt nichts entdecken können, dass die Aufgabe so "schwierig" oder besonders macht (fachlich), dass sie von Deinem Server erledigt werden muss, im Gegenteil.

Hole 1x pro Tag eine Datei von einem (anderen) Server.

Ich sehe auch keine "zusätzliche Abhängigkeit". Denn der Vorschlag von Phoenix ist mit Bordmitteln(Betriebssystem) problemlos zu erledigen, vollkommen transparent und mit wenigen Handgriffen auf neue Anforderungen adaptierbar. Diese Systeme funktionieren seit Jahrzehnten so zuverlässig, erprobt und transparent, wie man es selbst nur schwerlich hinbekommt.

Und der Administrator ist (meistens) leichter verfügbar, als der Entwickler, was m.E. eine deutlich geringere Abhängigkeit (des Systems) ist. Auch wenn Delphi "alles kann", es gibt zunächst nie einen Grund, Dinge für die man fachlich kein Spezialprogramm braucht, mit einem solchen zu erledigen. (Der einzige Grund wäre, gezielt Abhängigkeiten schaffen zu wollen).

Ist also Morgen die Anforderung plötzlich 2 Dateien zu holen statt eine, oder 2x am Tag eine oder oder, dann muss der Entwickler ran. Ein separates Skript mit OS Scheduler wäre in ein paar Minuten vom Admin umgestellt, ebenso geänderte Quellserver, gesperrte, verlorene Accounts, nicht mehr verfügbare oder geänderte Transferprotokolle, firewall Änderungen .. <nach Belieben erweiterbar>

Zuletzt ist ein Scheduled Task (oder Cronjob) mit einer so unauffälligen Aufgabe einer Dateiübertragung 1/Tag via OS Werkzeug ein vollkommen transparenter und angemessen prominenter Vorgang auch aus Sicherheits - und Monitoring Perspektive.

Zu allerletzt hat man so ein Plus an Flexibilität, das nicht nur den Betreiber freuen wird. Die Strategie, die sich darin zeigt wird mehr und mehr auch in großen Unternehmen eingesetzt.

Jetzt aber wirklich als letztes
Ein Server ist ein Server und er soll immer laufen. Muss ein Server wegen der geänderten Anforderung bspw. nicht 1x pro Tag sondern 2x (oder was auch immer) erstens umprogrammiert und zweitens, gestoppt, ausgetauscht und neu gestartet werden, so ist das in mehrfacher Hinsicht ein Service Ausfall, der in keinem guten Verhältnis zum Nutzen steht. (Es ist schon ein paar Jahre her, aber ich habe irgendwann mal in irgendwelchen Windows Release Notes gelesen, dass mehr 90 Gründe für einen Reboot beseitigt wurden. Es klang trotz trockener Sprache etwas stolz - ihr versteht was ich meine)

Mag sein, dass das hier alles nicht zutrifft, weil sich das System in einer komfortablen Nische befindet, aber es hat mich gejuckt, es mal so aufzuführen. War ja ne Konzeptfrage.