Announcement

Collapse
No announcement yet.

Windows-Dienst Überschneidungen der Ticks vermeiden - best practise?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Windows-Dienst Überschneidungen der Ticks vermeiden - best practise?

    hallo,
    ich habe einen Dienst der über einen Timer alle 5 Minuten etwas verarbeitet. Ich habe immer das Problem wenn der Dienst mal deaktiviert war die erste Verarbeitung sehr lange dauert. Also länger als 5 Minuten. Da der Timer alle 5 Minuten die Verarbeitung erneut startet, überschneiden sich zwei (oder ggf. auch mehrere) Verarbeitungen.


    Wie ist die best practise für dieses Problem?

  • #2
    Vor dem Start prüfen, ob die vorige Verarbeitung des Timers abgeschlossen ist
    Christian

    Comment


    • #3
      Je nachdem wie komplex das ist kannst Du Dir auch mal überlegen ob Du vielleicht Quartz reinbauen willst. Das Framework stellt Dir z.B. sicher dass ein Job immer nur einmal läuft und nicht mehrere Instanzen gleichzeitig davon.

      Comment


      • #4
        Wenn es einfach nacheinander laufen soll und gar keinen fixe Dauer bzw. fixen Zeitpunkt wo es passieren muß dann würde ich einfach gar keinen Timer oder Scheduler nehmen sondern einfach einen Thread in Endlosschleife mit einem Thread.Sleep als Pause zwischen den Ausführungen.

        Comment


        • #5
          Streng genommen, müsste ein Job, der nur einmal gleichzeitig läuft sich selbst überwachen <Punkt>
          Alles andere bietet schon genügend Spielraum für Fehler.
          In einen Windows Scheduler noch mal eine Java timer lib (quartz oder was auch immer) einzubauen, spricht sicher auch gegen irgendein Prinzip, dessen Name mir grad nicht einfällt.
          Wie auch immer, keep it simple....


          P.S.: Also der Klarheit halber mit "Job", meinte ich oben nicht den Schedulereintrag, sondern das Teil, dass die Arbeit tut.
          Gruß, defo

          Comment


          • #6
            In einen Windows Scheduler noch mal eine Java timer lib
            http://www.quartz-scheduler.net/
            Zwar kommt Quartz von Java, aber das ist eine reine NET Implementation
            Zuletzt editiert von Christian Marquardt; 05.03.2014, 18:03.
            Christian

            Comment


            • #7
              Originally posted by defo View Post
              In einen Windows Scheduler noch mal eine Java timer lib (quartz oder was auch immer) einzubauen, spricht sicher auch gegen irgendein Prinzip, dessen Name mir grad nicht einfällt.
              Wie auch immer, keep it simple....
              Solange ich nur einen Job habe und der nicht zeitlich genau auf den Punkt erfolgen muss kann man Thread.Sleep() verwenden. Das finde ich auch die eleganteste Lösung. Bei uns in der Firma laufen allerdings jede Menge verschiedene Jobs innerhalb eines Prozesses und für diese Jobs nehmen wir Quartz. Bei uns ist nicht jeder Job ein eigener Prozess. Am Ende ist das natürlich eine Architekturfrage. Falls ich so eine extrem genaue Taktung brauche oder dass der Job auf keinen Fall 2 mal parallel gestartet wird, würde ich schon so ein Framework empfehlen. Das sind gelöste Probleme über die ich möglichst nicht mehr selbst stolpern möchte. Klar haben die Frameworks auch einen Overhead. Quartz benötigt z.B. eine Persistenzschicht in der Trigger, laufende Jobs usw. gespeichert werden. Ausserdem wird darüber auch gesteuert dass ein Job ggf. nur einmal gestartet wird.

              Comment


              • #8
                Ich wollte mich nicht gegen Quartz aussprechen. Wir setzen das auch irgendwo ein.
                Es ging ja um best practice. Dein Beitrag klang etwas danach, innerhalb des Windows Schedulers noch einmal Quartz einzusetzen. Was vielleicht auch gar nicht so gemeint war.
                Ich würde auf einem Windows System solange mit dem Scheduler arbeiten, wie es geht. Erst dann über einen Ersatz nachdenken. Unter linux entsprechend cron, unter Oracle den Oracle scheduler usw.
                Der ausschlaggebende Punkt ist im Thread hier m.E., dass das Processing selbst kritisch ist und sich eigenverantwortlich absichern muss. Es ist nicht sichergestellt, dass im Rahmen von Administration, Deployment usw. ein Prozess ausschließlich über einen Scheduler gestartet wird. Im Gegenteil, bevor ich etwas automatisiere, rufe ich Prozesse manuell auf. Wenn der Prozess nicht mehrfach laufen darf und sich also am besten selbst abbricht bei Verletzung dieses Kriteriums, kann ich wunderbar mit Bordmitteln (also hier Windows Scheduler) arbeiten und habe mir oder den Admins diverse Komplexitätsgrade gespart. Außerdem arbeite ich so mit einem hochintegrierten, erprobten und bekannten Verfahren.
                Gruß, defo

                Comment


                • #9
                  @defo: Geb ich dir volkommen Recht

                  Comment


                  • #10
                    Der Windows Scheduler (und Cron) wird hier nicht benutzt und würde nicht helfen da es nicht um die zeitgesteuerte Ausführung von Prozessen geht. Hier gehts um die zeitgesteuerte Ausführung einer Aufgabe in einem Prozess. Und das nicht mal in irgendein Prozess sondern einem Dienst. Nur wenn das die einzige Aufgabe des Dienstes wäre und es zwischen den einzelnen Ausführungen der Aufgabe keinen Zusammenhang gibt (geteilte Daten) dann könnte man sich fragen ob ein Dienst unfug ist und man besser eine Executable nimmt und die einem OS Prozess Scheduler unterordnet. Wir sollten aber in erster Näherung erstmal davon ausgehen das openshinok weiß was er tut.

                    Comment


                    • #11
                      Dienst!=Windows Scheduler, das ist richtig. Da habe ich nicht richtig aufgepasst. Was allerdings nichts an meiner Meinung ändert, dass man Steuerhoheit nicht ohne Not (und Plan) in verschiedene Verantwortlichkeiten geben sollte.
                      Wenn also gar kein Scheduler im Spiel ist, und der Dienst permanent läuft (außer er ist disabled), was spricht dann dagegen, dass der Dienst etwas besser auf sich selbst aufpasst und eine Verarbeitung nicht beginnt, wenn bereits eine läuft?
                      Und das Wesen eines Forums begründet sich ja darauf, dass die Teilnehmer oft nicht wissen, was sie tun, daher dann eine Frage stellen, Nachfragen erhalten, Hohn und Spot ernten oder Antworten bekommen. Ich kenne die Teilnehmer nicht persönlich und führe auch nicht Buch über deren Skills.
                      Gruß, defo

                      Comment


                      • #12
                        Wenn also gar kein Scheduler im Spiel ist, und der Dienst permanent läuft (außer er ist disabled), was spricht dann dagegen, dass der Dienst etwas besser auf sich selbst aufpasst und eine Verarbeitung nicht beginnt, wenn bereits eine läuft?
                        Genau das was der Kern der Frage so wie ich sie verstanden habe Und das Windows Scheduler Thema empfand ich da dann als arg Off Topic.

                        Falls du bei mir Hohn und Spot findest bitte ich dich (und alle anderen) darum mir das um die Ohren zu hauen. Ironie könnt ihr mir aber hoffentlich verzeihen.

                        Comment


                        • #13
                          Originally posted by Ralf Jansen View Post
                          Genau das was der Kern der Frage so wie ich sie verstanden habe Und das Windows Scheduler Thema empfand ich da dann als arg Off Topic.
                          Falls du bei mir Hohn und Spot findest bitte ich dich (und alle anderen) darum mir das um die Ohren zu hauen. Ironie könnt ihr mir aber hoffentlich verzeihen.
                          Dann haben wir ja langsam alle Missverständnisse geklärt, muss ich wohl demnächst besser hinschauen.
                          Meine "Forenbeschreibung" war ganz allgemein gehalten und weder haargenau auf dieses Forum, geschweige auf Dich gemünzt.
                          Ironie macht mir Spaß (natürlich nur falls ich es bemerke) und ist mir immer willkommen, auch und gerade in einem Forum wie diesem, wo die Tendenz doch recht stark zur Sachlichkeit geht (oder darüber hinaus)
                          Gruß, defo

                          Comment

                          Working...
                          X