Thread freigeben, wenn er festklebt :)

[MyRealName]

Hallo,

hab mal eine Frage...
Ich lagere gerade einige DB Prozesse in einen service aus, welcher wiederrum auf dem Server läuft. Dazu habe ich mir einen ThreadPool gebaut und Datenbanken klassifiziert, ob sie in einem Thread allein laufen (weil viel genutzt), oder ob sie ihn sich mit 3 oder 15 DBs teilen (Also max DBs ist 1, 4 oder 16 bis jetzt)
In denen führe ich eine stored procedure aus (über UniDAC), welche dann entscheidet, welche Aufgabe erledigt werden soll. Soweit, so gut.. das geht auch alles sehr schön und flink, auch die Erzeugung und Schliessung von Threads.
Jetzt kommt der theoretische Fall den ich bedenken muss :

Wenn die Stored Procedure aus irgendwelchen Gründen mal nicht zurück kommt, klebt sich der thread ja fest (und wenn er geshared ist mit anderen DBs, wird bei denen ja auch nichts mehr ausgeführt). Dazu habe ich ein Ping Pong eingebaut über Windows Nachrichten, welche alle 30 sekunden die threads fragt, ob sie noch leben. Heisst, wenn ein thread nicht antwortet, schlägt der timer nach 30 sekunden wieder auf und erkennt, dass der thread nicht geantwortet hat und soll ihn beenden und neu erstellen (habe alle information, um ihn neu zu starten).

Problem ist, beim Thread.Free bleibt alles stehen dann. wenn threads sich normal dort beenden (weil der letzte User raus ist), geht alles toll. Aber ich kann ja nicht Terminated auf true setzen, weil der thread ja blockiert ist.

Gibt es ideen ?

Code:

    Try
      UsageLevel := vtThreadDataUsageLevel.Value;
      OldThreadId := vtThreadDataThreadId.Value;
      EnterCriticalSection(aCriticalSection);
      FpThread := TDatabaseConnectionThread(Pointer(vtThreadDataaObj.AsInteger));
      FpThread.Free;
      LeaveCriticalSection(aCriticalSection);
    except
      On E: Exception Do
        CodeSite.Send( csmLevel1, 'Error deleting thread', E.Message);
    End;

[BUG]

Um die beste Möglichkeit direkt auszuschließen: Die UniDAC-Komponenten bieten keinen Timeout für einen Request an?
Leider musst du davon ausgehen, das die Datenbankverbindung (oder die gesamte Bibliothek) nicht mehr korrekt funktioniert kann, wenn du den ausführenden Thread zwischendurch einfach abschießt :|

Außerdem springt mir ins Auge, dass du deine Critical Section nie freigibst, wenn im Folgenden ein Fehler auftritt:

Delphi-Quellcode:

      FpThread := TDatabaseConnectionThread(Pointer(vtThreadDataaObj.AsInteger));
      FpThread.Free;

Was schützt die CS denn genau?

[Sir Rufo]

Zitat:

Zitat von BUG (Beitrag 1295605)

Außerdem springt mir ins Auge, dass du deine Critical Section nie freigibst, wenn im Folgenden ein Fehler auftritt:

Delphi-Quellcode:

      FpThread := TDatabaseConnectionThread(Pointer(vtThreadDataaObj.AsInteger));
      FpThread.Free;

Was schützt die CS denn genau?

Ich vermute, dass ist eine CS die als Argument übergeben wird (wegen aCriticalSection)

[himitsu]

Was heißt denn hängen/festkleben?
Bzw. warum hängt der denn?

Gerade in einem Service, vorallem wenn der länger läuft, sollte man beser alles ordentlich beenden und vorallem die Resourcen richtig freigeben, was durch Abschießen praktisch nicht möglich ist.


PS: Da du natürlich keine Resourcenschutzblöcke verbaut hast, gibt es bei einer Exception einen geilen Deadlock in deiner aCriticalSection. :stupid:

[MyRealName]

festkleben heisst, dass eine Stored Proc nie wieder kommt und UniDAC für immer wartet. Das blockiert den Thread.

aCriticalSection ist eine globale variable im MainThread, welche beim erstellen des Services erzeugt wird und auch wieder freigegeben wird.
Und die Option des Abschiessens ist nicht... ähm... optimal, aber eine stored proc in dem Kontext sollte nie länger als 1-3 Sekunden dauern, wenn es länger dauert, dann ging was unerwartetes schief und ich muss das mit einbedenken.

[Dejan Vu]

Wie kann denn eine SP nie zurückkommen? Die Frage sollte mit 'NIE' beantwortet werden.

[MyRealName]

Eine option ist zum Bsp. die WAIT Transaction, die nicht einen lock conflict herbeiführt, sondern wartet bis die andere ihre updates abgschlossen hat. Hatte Falle wo niemand mit einer DB verbunden war und ich die SP nie zurück kam in der WAIT transaction. eine NO_WAIT brachte sofort einen lock conflict, obwohl niemand dort war. Ein Neustart von Firebird brachte die Lösung.

UniDAC hat keine Option, "normal" zu beenden mit TimeOut oder so. UniDAC blockiert immer den ganzen Thread.

[Dejan Vu]

Mein Beitrag ging in die Richtung: Dann würde ich diese Implementierung überdenken bzw. dafür sorgen, das eine Query/SP nie hängt. Das sollte mit FB doch zu machen sein.

"Abschießen" o.ä. ist jedenfalls die unsauberste aller Implementierungsoptionen.

Alternativ kann man sich asynchron verbinden und die Verbindung bei Zeitüberschreitung beenden. Ob das mit UniDAC geht, weiß ich nicht.

Edit: Ich verstehe zwar nicht genau, was der TE mit 'DB' meint, und das ein Thread sich DBs teilt, aber grundsätzlich würde ich das nicht so lösen, sondern über einen Connectionpool. Pro Anfrage ein Thread, die sich aus dem Pool bedienen. Das löst das Problem zwar nicht, dürfte aber um vieles einfacher sein.

[MyRealName]

Es ist ein Connection Pool, aber ich mache nicht pro Anfrage ein thread, weil das viel zu lange dauert. Manchmal habe ich nach einer Kostenneuberechnung im System ein paar tausend Dokumente neu zu buchen in der Buchhaltung (deren Bewegung vom Inventarkonto zum Ausgabenkonto). Pro Dokument kann das in total schonmal 1-2 Sekunden dauern. Wenn ich für jede von diesen Aufgaben enen neuen Thread machen wurde, wäre der Overhead an Zeit einfach zu gross. Ich kriege ja schon Mecker vom Chef, weil ich die nicht im Block abarbeite, sondern ene transaktion für jede mache und mir in Sammelthreads sogar noch zeit für andere DBs nehme ;)

Klar, die beste Lösung ist wenn die SP nie hängt, aber das schafft man auch nur zu 99%. Da kommen viel Faktoren mit rein. Versuche nur, an alles zu denken und auch die 1% abzudecken :)
Unsere DB hat knapp 400 stored procs und ein paar hundert Trigger. In Kombination mit den Daten kann es da zu seltsamen zusammenspielen kommen, die man nicht im vorraus sieht.

[Dejan Vu]

Oh.. Also 'as is'. Na ja. Dann muss man es eben so machen.

Wie wäre es mit Workerthreads, die eine Jobliste abarbeiten? Einen Workerthreadpool gibts hier im Forum.

Falls es untergegangen sein sollte: Imho sollte nicht der Thread abgeschossen werden (geht nicht, nur schlafenlegen geht), sondern die Connection. Und das sollte FB drauf haben. Oder Du lässt dir dir PID von der Connection geben (oder wie auch immer das bei FB heißt) und killst Du dann (wenn das bei FB geht).

[mkinzler]

Bei Firebird geht das über die Monitoringtabellen (MON$STATEMENTS in diesem Fall)

[MyRealName]

Zitat:

Zitat von mkinzler (Beitrag 1295837)

Bei Firebird geht das über die Monitoringtabellen (MON$STATEMENTS in diesem Fall)

Kannst Du das mal etwas genauer erklären bitte?

[4dk2]

Ist zwar schon nen bisl älter das Thema, aber ich hab auch genau den Fall,
und da hier auch nur nach den Auslösern fürs Hängen gesucht wurde, Frage ich nochmal :)

Ich möchte einen Thread abschießen, der nicht mehr reagiert.
Warum der hängt, soll egal sein ;)
Z.b. es wrid im thread ne funktion aus einer DLL aufgerufen die dann in einer Schleife festhängt,
und auf die DLL hat man keinen Einfluss.

Die Wege fürs normale beenden sind mir bekannt, funktionieren aber nicht.

Was ich bisher mache:
1.FreeOnTerminate setzen, in der Hoffnung das er sich irgendwann mal beendet, im Fehlerfall.
2.Thread Normal terminieren, im Timeout Fall /Fehler
3.Neuen Thread erstellen der die Aufgabe übernimmt :lol:

Bei meiner Simulation, kommt beim beenden des Programmes der Destructor von dem Toten Thread NICHT zum tragen.

Alternativ hab ich schon nachgedacht, den Programm Zustand zu merken und Programm neuzustarten :oops:

Was mich interesstiert:
-Möglichkeit den Thread zu killen,
-TerminateThread(MSDN link), funktioniert nicht, bzw vielleicht hab ichs falsch implemtniert? S.u.

Mein ThreadTerminate das net geht:

Delphi-Quellcode:

    FWorker.Terminate;
    StartTimeout(tmpTO,'StopThread_tmpTO',3000);

    //das hier sollte man natürlcih net tun wenn FreeOnTerminate gesetzt ist...
    while not FWorker.Finished and not isTimeout(tmpTO) do
    begin
      Application.ProcessMessages;
    end;

    //FORCE KILL:
    if isTimeout(tmpTO) then
    begin
      System.SetLastError(ERROR_SUCCESS);
      iThreadExitCode:=0;
      if not GetExitCodeThread(FWorker.ThreadID,iThreadExitCode) then
      begin
        sMsg:=SysErrorMessage(GetLastError); //== 'Das Handle ist ungültig' , ist es aber nicht windows :P
        showmessage('Fehler1');
      end;


      System.SetLastError(ERROR_SUCCESS);
      bOK:=TerminateThread(FWorker.ThreadID,iThreadExitCode);
      if bOK then
        showmessage('OK');
      else
      begin
        showmessage('Fehler2')
        sMsg:=SysErrorMessage(GetLastError); //kein OS error vorhanden
      end;
    End;

[jaenicke]

Wenn z.B. ein Socket gerade hängt, bekommst du den Thread nicht gekillt bevor das Timeout kommt.

An der Stelle wäre dann ein Multiprozessmodell wie in Google Chrome sinnvoll. Das wurde ja genau aus den Gründen eingeführt um hängende oder abgestürzte Tabs zu behandeln ohne dass der Browser selbst abstürzt. Das funktioniert in anderen Browsern ja bis heute nicht richtig.

Einen solchen externen Prozess kannst du in fast allen Fällen abschießen. Es gibt allerdings auch dafür Grenzen. Manchmal kann man nicht einmal einen solchen Prozess abschießen. Diese Fälle sind aber selten.

[Der schöne Günther]

Zitat:

Zitat von 4dk2 (Beitrag 1381955)

funktioniert nicht, bzw vielleicht hab ichs falsch implemtniert?

Windows hat sehr wohl recht - Du gibst ihm die Thread Id. Die WinApi-Mehtode

Delphi-Quellcode:

GetExitCodeThread

möchte aber ein Handle, nicht die ID.

[Dalai]

In Fortsetzung der Ausfürungen des schönen Günther: Dasselbe trifft auf TerminateThread zu. D.h. erst OpenThread rufen, um das Handle zu ermitteln und dann mit diesem weiterarbeiten (und nicht vergessen, CloseHandle am Ende aufzurufen).

Grüße
Dalai

[Luckie]

Es ist eben meist immer besser das Kind nicht erst in den Brunnen fallen zu lassen. Was sagt denn der Entwickler der DLL zu dem Problem?

[Der schöne Günther]

Zitat:

Zitat von Dalai (Beitrag 1381982)

D.h. erst OpenThread rufen, um das Handle zu ermitteln und dann mit diesem weiterarbeiten (und nicht vergessen, CloseHandle am Ende aufzurufen).

Nicht notwendig, wir haben hier doch einen

Delphi-Quellcode:

TThread

, und der hat direkt schon die Eigenschaft

Delphi-Quellcode:

Handle

.

[4dk2]

Delphi-Quellcode:

GetExitCodeThread(FWorker.Handle,iThreadExitCode)

gibt ok zurück
aber

Delphi-Quellcode:

TerminateThread(FWorker.ThreadID,iThreadExitCode) = false

Ich kann aber z.b. mit dem process Explorer von Sysinternals den toten Thread killen.
Dann muss es doch auch eine Interne Möglichkeit geben oder?

[jaenicke]

Ich vermute einmal du musst wie Dalai geschrieben hat mit OpenThread arbeiten. Ich bezweifle, dass das Handle, das standardmäßig in der Eigenschaft Handle liegt, das Zugriffsrecht THREAD_TERMINATE hat. Siehe Dokumentation.

Dir muss aber klar sein, dass die Verwendung von TerminateThread das ganze System instabil machen oder zum Absturz bringen kann, wenn man nicht ganz genau weiß was man da tut. Deshalb ja auch die dringende Warnung in der Dokumentation:

Zitat:

TerminateThread is a dangerous function that should only be used in the most extreme cases.

Insbesondere bei Verwendung von fremden DLLs, auf die man keinen Einfluss hat, wie du eingangs geschrieben hast, ist das hochkritisch.

Sollte das eine Business Anwendung sein, wäre das schon ein NoGo für deren Einsatz in vielen Fällen.

[Stevie]

Zitat:

Zitat von Larry Osterman

How many times does
it have to be said: Never
call TerminateThread.

Siehe https://blogs.msdn.microsoft.com/old...14-00/?p=91811

[Dalai]

Zitat:

Zitat von 4dk2 (Beitrag 1382012)

aber

Delphi-Quellcode:

TerminateThread(FWorker.ThreadID,iThreadExitCode) = false

Weil du immer noch die Thread ID benutzt statt des Handles.

Generell stimmt ich aber zu: Priorität sollte haben, zu verhindern, dass der Thread hängt. Warum er das tut, kann natürlich keiner sagen außer dir selbst.

Grüße
Dalai

[4dk2]

Danke für eure Hilfe, es Funktioniert jetzt.

Delphi-Quellcode:

      iThreadID:=FWorker.ThreadID;
      hThread:=OpenThread(THREAD_TERMINATE or THREAD_QUERY_INFORMATION ,false,iThreadID);
      if hThread<>0 then
      try

        System.SetLastError(ERROR_SUCCESS);
        iThreadExitCode:=0;
        if not GetExitCodeThread(hThread,iThreadExitCode) then
          sMsg:=SysErrorMessage(GetLastError);

        System.SetLastError(ERROR_SUCCESS);
        bOK:=TerminateThread(hThread,iThreadExitCode);
        if bOK then
          sMsg:='OK'
        else
        begin
          sMsg:=SysErrorMessage(GetLastError);
        end;
      finally
        CloseHandle(hThread);
      end;

[Der schöne Günther]

PS: Ohne auf die Notwendigkeit von TerminateThread(..) einzugehen: Das ständige Zwischenspeichern des Rückgabewertes, SysErrorMessage usw. lässt sich vereinfachen: Schau dir mal den Aufruf

Delphi-Quellcode:

System.SysUtils.Win32Check(..)

an.