QUIT in Multi-Thread-Anwendung mit großem ?

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Antworten
psp
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 250
Registriert: Do, 22. Okt 2009 13:42
Kontaktdaten:

QUIT in Multi-Thread-Anwendung mit großem ?

Beitrag von psp »

Hallo,

ich habe bei einem Kunden aktuell Probleme mit einer Datenbank, die exklusiv in einer Multi-Thread-Anwendung geöffnet und verwendet wird.

Das Programm hat 3 + x laufende Threads. x ist vernachlässigbar, da die mit mit einer Schleife auf ein Event warten, was nur extern ausgelöst wird.

Der 1. Thread ist die Oberfläche, der 2. ein Kommunikationsthread mit einer exklusiven DBF A und ein weiterer Kommunikationsthread (der 3.) mit einer exklusiven DBF B.

Der 1. und der 2. Thread laufen wie gewünscht. Der 3. Thread erzeugt sporadisch Fehler auf meiner DBF B, sei es beim dbAppend, dbPack, OrdListRebuild ("Fehler beim Schreiben"), dbCloseArea ("Fehler beim Schließen einer Datei") oder ähnlichem mit dem ebenso berühmten Fehlercode 8999. Eben war es dbPack und OrdListRebuild. Diese Funktionen sind mittlerweile abgeleitet und sind mit einer BEGIN SEQUENCE-Schleife abgesichert mit einer ausreichenden Anzahl an Versuchen und Wartepausen und notfalls einen Programmabbruch mit automatischen Programmneustart endet. Daher ein paar Details, das dbPack ging im zweiten Versuch gut und das Programm ging weiter und hat den OrdListRebuild gestartet. 10 Versuche reichten hier nicht aus und gaben den Fehlertext "Fehler beim Schreiben" aus, der anschließende Programmneustart (runshell mit lAsync=.T.) wird im Programmteil eingeleitet und anschließend folgt ein QUIT. Der 2. und 3. Thread haben jeweils einen eigenen Workspace, in dem alle anderen notwendigen Datenbanken geöffnet sind - in diesem Fall halt doppelt geöffnet, was sich bisher nicht als Problem heraus stellt.

Wie jetzt jeder sicher wissen müsste, kann das Programm erst richtig starten, wenn das alte beendet ist. Daher wartet das neu gestartete Programm erstmal ein paar Sekunden (6 sind es aktuell), bevor es irgendwas macht. Das Programm was ja in das QUIT gelaufen ist, wird jedoch laut Kundenaussage nicht beendet, es wäre noch in der Taskleiste sichtbar. Daraus folgt, dass das neu gestartete Programm nicht anläuft, weil es beide exklusiven Dateien nicht öffnen kann, das bekomme ich in meinem Fehlerprotokoll quitiert.

Mir geht bei dem Kunden mein Latein aus. Die Umgebung ist ein virtueller Server mit Windows Server 2008 R2, ohne Virenscanner in der virtuellen Umgebung - zumindest sehe ich offensichtlich keinen. Bei anderen Kunden haben wir nicht mal ansatzweise solche Probleme. Es ärgert mich umso mehr, dem Kunden Möglichkeiten zu bieten zu müssen, wie man sowas verhindern kann und Anforderungen an das System werden als erfüllt abgetan. Begründungen für die Ursache fallen mir schon keine mehr ein, zumal die Fehler nun schon mehr als hardwarenah ersichtlich sein müssten. Es geht sogar soweit, dass ich in meiner normalen Tätigkeit eingeschränkt werde, weil allein die Prüfung aller Merkmale eine Menge Zeit verschlingt.

Ich hoffe, ihr habt noch ein paar Anregungen.
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: QUIT in Multi-Thread-Anwendung mit großem ?

Beitrag von georg »

Hallo,


ein Ansatz ist es, Referenzen zu den Threads in einem Array zu halten und an jeden Thread ein User-Event zu senden, das Du im jeweiligen Event-Loop abfragst. Kommt dieses Event, beendest Du den jeweiligen Thread. Auf diese Art und Weise solltest Du zumindest die Kontrolle haben.

Ansonsten ist mir ein solches Verhalten bisher nicht begegnet. Aber eine tolle Basis, mal über eine SQL-Migration nachzudenken, da genau diese Probleme dort so gut wie nie auftreten.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen 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: QUIT in Multi-Thread-Anwendung mit großem ?

Beitrag von Tom »

Die erste Frage, die ich protokollieren würde, wäre jene, ob das QUIT überhaupt erreicht wird.

Ich habe für solche Fälle vor das eigentliche QUIT eine Prozedur gesetzt, die in einer Sequenz ein DbCommitAll() und DbCloseAll() ausführt, außerdem entlädt es ggf. geladene externe DLLs (Drittprodukte) und zerstört Jobs des Formulargenerators, deren DLLs anschließend ebenfalls entladen werden. Nach meiner Erfahrung sind/waren es vor allem geladene Fremd-DLLs, die dazu führten, dass sich ein Programm nicht wirklich beendete und/oder DLLs geladen blieben - auch solche, die zur Applikation direkt gehörten. Aber, wie gesagt - der erste Schritt wäre die Klärung der Frage, ob das QUIT im Fehlerfall überhaupt erreicht wird.
Herzlich,
Tom
psp
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 250
Registriert: Do, 22. Okt 2009 13:42
Kontaktdaten:

Re: QUIT in Multi-Thread-Anwendung mit großem ?

Beitrag von psp »

Das ist der Block aus meinem Protokoll. Die Threads arbeiten zwangsweise mit einem unterschiedlichen Century-Wert.

Code: Alles auswählen

11.07.13 10:33:08: Fehler beim Packen in Datei TERMDAT001 - DBPack - Beschreibung: D BUCH_OFFLINE(547) PROC_THREAD(4391)  Versuche: 1/10
11.07.13 10:33:10: Fehler beim Neuaufbau der Index-Dateien bei Datenbank TERMDAT001 - OrdListRebuild - Beschreibung: Fehler beim Schreiben BUCH_OFFLINE(551) PROC_THREAD(4391)  Versuche: 10/10
11.07.2013 10:33:10: Online Thread abgestürzt Proc_thread
11.07.2013 10:33:10: Programm abgebrochen durch Fehler
11.07.2013 10:33:11: Schließe alle Datenbanken
11.07.2013 10:33:11: Beende Service 0
Der von uns integrierte Watchdog registrierte sogar, dass der Proc_Thread abgestürtz ist. Beende Service 0 ist mit die letzte Meldung, danach folgt ein Text-Eintrag für die Abmeldung des Programms, der auch da ist und nach dem FClose kommt das QUIT.

Das Problem, was ich beim QUIT sehe, dass es auch ein CommitAll und ein CloseAll macht - laut Hilfe. Was ist, wenn das auch nicht gut gehen kann und damit nicht mehr beendet wird? Damit wäre die Frage @Tom, ob das CommitAll() und CloseAll() manuell zu dem gewünschten Ergebnis führen könnte, wenn das QUIT nicht mal in der Lage dazu ist. Ein härterer Programmabbruch ist mir leider nicht bekannt.

SQL wird es geben, soweit sind wir uns sicher. Aber garantiert nicht mit Alaska XBase ++, nachdem die Subscription letzte Woche auslief und ein Gespräch uns nicht dazu bewogen hat, die Subscription zu verlängern.
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: QUIT in Multi-Thread-Anwendung mit großem ?

Beitrag von Tom »

QUIT referenziert die Funktion _quit(). Denkbar, dass in dieser Dinge mit Tabellen geschehen, die wiederum zu einem Fehler führen können, so dass das eigentliche Exit nicht ausgeführt wird. Deshalb habe ich ja meine eigene Funktion davorgesetzt, die die genannten Funktionalitäten in einer Sequenz (bei Fehler: Break) vornimmt. Seitdem habe ich ähnliches Verhalten nicht mehr bemerkt.
Herzlich,
Tom
Antworten