Dienste und errorsys

Fragen rund um diverse Windows-Versionen, ihr Verhalten unter Xbase++ und den Umgang mit der API

Moderator: Moderatoren

Antworten
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Dienste und errorsys

Beitrag von Werner_Bayern »

Servus,

hab grad meinen ersten Dienst fertiggestellt, läuft schon auf unserem Server. Aber wie macht ihr das mit der errorsys? Falls es kracht, kommt ja entweder eine msg., ein alert oder ein confirmbox - je nach AppType.

Ich hab mir jetzt mal die Original-errorsys etwas angepasst, aber wohl ist mir dabei nicht.

Da fällt mir auf:

Code: Alles auswählen

#ifndef    DEBUG
#define  DEBUG
#endif
Was macht das für einen Sinn? Ist ja der Original-Code aus dem sys-Ordner...
es grüßt

Werner

<when the music is over, turn off the lights!>
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Dienste und errorsys

Beitrag von ramses »

Hallo Werner

am besten geht dies nur durch eine komplett neu erstellte auf "Dienste" angepasste ErrorSys die auf einen Benutzerlosen Ablauf ausgerichtet ist.

So habe ich z.B. die Programme die als Dienst laufen immer als Consolen-App aufgebaut, so kann das Programm immer als Dienst oder Programm ausgeführt werden. Fehler gebe ich einfach mit ? auf die Konsole aus, Loge diese und sende dem Admin eine e-Mail.
Ein 2. Dienst überwacht den ersten und führt bei Bedarf einen Neustart des primären Dienst aus.
Valar Morghulis

Gruss Carlo
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Dienste und errorsys

Beitrag von Jan »

Werner,

für meine Programme und die meiner Kunden habe ich die erorsys u. a. so umgeschrieben, das ich immer auch eine Mail bekomme. Das wäre ja vermutlich genau das was Du benötigst. Wobei Du dann eventuell auch die Bildschirmausgabe des Fehlers im zusätzlichen Fenster abschalten könntest, damit das Programm ohne Nutzereinwirkung beendet ist.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Dienste und errorsys

Beitrag von Tom »

Bei Diensten ist vor allem wichtig, dass sie überhaupt laufen. Wir haben alle wesentlichen Prozesse in unseren zwei Hauptdiensten (Server/Backend, Servicedienst) in einzelne Sequenzen gekapselt, etwa das Beantworten einer REST-/SOAP-Anfrage mit komplexen Daten oder ein Teilbackup oder so. Wenn darin ein Laufzeitfehler auftritt, wird der Fehler getrackt (mit Callstack u.v.a.m.) und protokolliert und ggf. per Mail an uns gemeldet, aber der Dienst läuft weiter (und versucht ggf., den Vorgang zu wiederholen). Nur der Dienstcontroller, der im gleichen Code liegt und eine UI hat, darf notfalls in der Errorsys landen. Der Dienst selbst muss so gebaut sein, dass er vor allem verlässlich läuft, schließlich sieht man ihn ja nicht dabei. Das kann man dann auch aus den eigentlichen Applikationen heraus verfolgen, also den Status prüfen, wenn man will (dafür gibt es jeweils einen Subserver). Serverdienste sind für Leute draußen wichtig, und die haben überhaupt keinen Zugriff auf das System.

Außerdem sollte in den Eigenschaften des Dienstes eingestellt sein, dass er sich nach Fehlern neu startet (Karteireiter "Wiederherstellen" in den Eigenschaften des Dienstes). Und das muss er natürlich bewältigen, also wissen, wie das geht.
Herzlich,
Tom
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Dienste und errorsys

Beitrag von Tom »

Ach so:
Da fällt mir auf:
Der Codeschnipsel sorgt nur dafür, dass "DEBUG" immer definiert ist. In der Standard-Errorsys wird das wiederum abgefragt, um in der Abfrage, wie nach dem Fehler fortgefahren werden soll, den "EXIT_WITH_LOG" anzubieten. Kommentiert man es aus, gibt es keine Errorlog, also keine XPPERROR.LOG.
Herzlich,
Tom
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Dienste und errorsys

Beitrag von Werner_Bayern »

ramses hat geschrieben: Di, 09. Nov 2021 6:45 Hallo Werner

am besten geht dies nur durch eine komplett neu erstellte auf "Dienste" angepasste ErrorSys die auf einen Benutzerlosen Ablauf ausgerichtet ist.

So habe ich z.B. die Programme die als Dienst laufen immer als Consolen-App aufgebaut, so kann das Programm immer als Dienst oder Programm ausgeführt werden. Fehler gebe ich einfach mit ? auf die Konsole aus, Loge diese und sende dem Admin eine e-Mail.
Ein 2. Dienst überwacht den ersten und führt bei Bedarf einen Neustart des primären Dienst aus.
Servus Carlo,

danke. Sowas sollte eigentlich als Standard in der errorsys drin sein... Leider kann man da auch nicht mit AppType() arbeiten, weil das keinen Dienst erkennt. Werde also unsere aktuelle errorsys extra per Compile-Konstante an Dienste anpassen müssen.

Interessanter Ansatz, bisher hab ich den Dienst als Gui-App eingestellt, weil man dann sauber mit der Workbench debuggen kann, entsprechende Fehlermeldungen sieht und kein Fenster erzeugt wird (Appsys ist leer). Wenn Konsole als Typ eingestellt wird, erscheint immer das CMD-Fenster, das stört mich, braucht keiner. Dachte auch, das mag die Anwendung als Dienst dann nicht.
Bei Dir erzeugt also der Dienst ein unsichtbares Konsole-Fenster?
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Dienste und errorsys

Beitrag von Werner_Bayern »

Jan hat geschrieben: Di, 09. Nov 2021 6:55 Werner,

für meine Programme und die meiner Kunden habe ich die erorsys u. a. so umgeschrieben, das ich immer auch eine Mail bekomme. Das wäre ja vermutlich genau das was Du benötigst. Wobei Du dann eventuell auch die Bildschirmausgabe des Fehlers im zusätzlichen Fenster abschalten könntest, damit das Programm ohne Nutzereinwirkung beendet ist.

Jan
Servus Jan,

vermutlich hast Du hier Dienste überlesen?
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Dienste und errorsys

Beitrag von Werner_Bayern »

Servus Tom,

danke.

Ihr habt also die errorsys komplett umgebaut? Den automatischen Neustart des Dienstes hab ich schon auf 1x eingestellt, ist Standard bei uns. Ob er läuft, erkennt die zugehörige Applikation, da der Dienst eine Tabelle schreibt mit Timestamp und evtl. Meldungen und Fehlern. Dadurch kann ich den Benutzern dann sagen, wenn mit dem Dienst was nicht stimmt.
(und versucht ggf., den Vorgang zu wiederholen)
Gefährliche Geschichte für Endlos-Schleifen oder Fatals? Oder macht ihr das über die Eigenschaften im Dienst, also ein Sprung in die errorsys führt i. d. R. zum quit und Windows startet den Dienst dann neu?

Tom hat geschrieben: Di, 09. Nov 2021 9:05 Ach so:
Da fällt mir auf:
Der Codeschnipsel sorgt nur dafür, dass "DEBUG" immer definiert ist. In der Standard-Errorsys wird das wiederum abgefragt, um in der Abfrage, wie nach dem Fehler fortgefahren werden soll, den "EXIT_WITH_LOG" anzubieten. Kommentiert man es aus, gibt es keine Errorlog, also keine XPPERROR.LOG.
Irreführend. Der Debug-Schalter ist eigentlich anders definiert, so entsteht bei mir der Eindruck, dass die errorsys immer davon ausgeht, dass man im debug-Modus ist. Für die Errorlog sorgt doch wiederrum:

Code: Alles auswählen

         IF IsDebug() == .T.
            ErrorLog( oError, 2 )
         ENDIF
Muss ich mir nochmal genauer anschauen, hab ich vermutlich noch nicht ganz verstanden :?
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Dienste und errorsys

Beitrag von Tom »

Hallo, Werner.

Klar haben wir die Errorsys komplett umgebaut. Das ist für uns ein zentrales Werkzeug zur Sicherung der Softwarequalität auch in der Auslieferung. Wir reagieren darin aber auch auf bekannte Fehler, auf äußere Ursachen usw. usf. Das ist ziemlich umfangreich und ein wichtiges Tool.
Gefährliche Geschichte für Endlos-Schleifen oder Fatals? Oder macht ihr das über die Eigenschaften im Dienst, also ein Sprung in die errorsys führt i. d. R. zum quit und Windows startet den Dienst dann neu?
Ob und wie oft und unter welchen Bedingungen erneut versucht wird, etwas zu tun, hängt von der Situation ab. Und natürlich wird nicht beliebig oft wiederholt, sondern ein, zwei, drei Male - je nachdem. Wenn es dann nicht geht, teilt man beispielsweise dem Client mit, dass er es später noch einmal versuchen soll. Und es werden intern Nachrichten ausgelöst. Aber, nein, wir springen da nicht in die Errorsys - in der landet der Dienst praktisch nie. Die Sequenz (BEGIN SEQUENCE ...) trackt und protokolliert den Laufzeitfehler (wertet das Fehlerobjekt und einige anderen Daten aus) und beendet sich einfach. Dann wird sie ggf. wiederholt. In der Errorsys kommt man so überhaupt nicht an. Wenn ich z.B. im Server eine Session habe, die eine Sitzung repräsentiert, ist das gekapselt. Notfalls endet diese Session, und der Client muss es abermals versuchen - das ist ja keine Seltenheit im Netz, auch heuzutage noch. Und wenn er abermals reinkommt, wird erneut eine Session für ihn eröffnet, das alte Threadobjekt ist weg, der Fehler ist protokolliert. Und wenn der Client dann mehrfach nicht durchkommt, muss irgendwer nachsehen, welcher Fehler da warum immer wieder auftritt. Aber der Dienst läuft und kommt nicht in die Errorsys. Nie*. Das würde ihn killen.

Es ist auch für normale Applikationen wichtig, sich mit Sequenzen zu befassen. Manchmal sind Laufzeitfehler wahrscheinlich, etwa bei sehr umfangreichen automatisierten Prozessen, oder wenn man mit Drittprodukten redet, also beispielsweise Excel zu steuern versucht. Dann bettet man den ganzen Prozess in eine Sequenz und beendet die im Fehlerfall einfach. Ggf. sagt man den Benutzern, dass etwas schiefgelaufen ist und sie sich mal Excel anschauen sollten oder so. Aber das Programm läuft weiter. In Sequenzen führten Laufzeitfehler - je nach Programmierung - zum Abbruch der Sequenz und erlauben dann die Auswertung des Fehlerobjekts. Aber sie rufen in dieser Konstellation nicht die Errorsys auf.

*außer natürlich bei Zero Devides und Fehlern, die Retries ermöglichen, außerdem haben wir eine Reparaturautomatik für korrupte Indexe in der Errorsys verbaut, da retourniert sie dann entsprechend
Herzlich,
Tom
Antworten