Thread mit TRestRequest

[Incocnito]

Hi Zusammen,

ich habe eine Funktion, welche einen Rest-Request ausführt.
Läuft soweit. Nun war Ziel diesen in einen Thread auszulagern und
das Timeout auf 8 Stunden zu setzen. Ich wäre eher dafür mich
am Server zu registrieren und per TCP-Server auf eine Meldung zu warten,
aber ist nunmal nicht. Problem ist: Wenn ich den Thread beende

Delphi-Quellcode:

thrObj.Terminate();

dann soll natürlich die Anfrage abgebrochen werden (Meinetwegen dann auch mit
einem Timeout). Sicher, Delphi macht da selbst schon irgendwann Schluss, wenn ich das Programm absäge,
aber ich würde das gerne "selbst" steuern.
Gibt es eine Art TRestClient.OnExecuting/TRestRequest.OnIdle, welche man besetzen könnte, so dass ich in Unterfunktionen
sowas machen wie

Delphi-Quellcode:

if (TThread.CurrentThread.CheckTerminated()) then DoContinue := False;

?
Oer kann ich dem Rest-Request irgendwie sagen

Delphi-Quellcode:

restRequest.CancelOnThreadTerminated := True;

?
Für Ideen und Tipps wäre ich sehr dankbar!

Mit freundlichem Gruß
Incocnito

[DeddyH]

Was ist das denn für ein REST-Server, der 8 Stunden für die Abarbeitung einer Anfrage braucht?

[Der schöne Günther]

Das hat eigentlich nichts speziell mit REST zu tun, und auch nicht mit Threads. Die Frage ist: "Ich habe fertig. Wie breche ich das blockierende Warten ab?"?

Ich bin da auch nie zu einer zufriedenstellenden Lösung gekommen. Bei den Indy-TCP-Clients kann man aus einem Parallel-Thread die Verbindung schließen, dann hören auch die anderen Warte-Operationen auf da sie direkt fehlschlagen.

Ich bin mit nicht sicher, aber der TRestRequest geht mittlerweile nicht mehr über Indy, richtig? Stattdessen direkt über die WinApi. Ob man da etwas vorzeitig abbrechen kann?


Evtl. kommt man weiter wenn du im Debugger einmal anhälst und schaust wo dein Thread nun genau grade steht und wartet?

[Incocnito]

Hi Zusammen,

es handelt sich um ein Benachrichtigungs-System.
Sobald eine Nachricht erstellt wurde/ankommt/empfangen wurde vom Server/...
wird diese an die wartenden Rest-Clients geschickt. Es ist also keine Aufgabe,
welche 8 Stunden dauert. Wie gesagt, so geil finde ich den Ansatz nicht.
Der Kollege baut eine Art Sandbox-System, ich denke da ja das System auch durch
ein Update neu gestartet werden könnte und er auf Gedei und Verderb nach einem
Neustart immer in ein und den selben Zustand starten will. Und die Clients nur so
ein Ableben/Neustarten des Servers mit bekommen und sich neu "registrieren".
Naja long story short, nun soll es so gelöst werden, aber mich stört, dass die Threads
derzeit nicht "ordentlich" beendet werden.
Ob ich die Stelle finde, bei denen das blockiert muss ich schauen.

Liebe Grüße bis hierhin schonmal
Incocnito

[Klaus01]

.. wenn ein Client mit einem Server verbunden ist
und der Server dem Client etwas schickt, dann wird in der Regel
auf dem Client ein Event ausgelöst, da muss man den Server nicht
ewig pollen und schauen ob Nachrichten für den Client da sind.

Grüße
Klaus

[WiPhi]

Zitat:

Zitat von Incocnito (Beitrag 1491662)

Hi Zusammen,
Gibt es eine Art TRestClient.OnExecuting/TRestRequest.OnIdle, welche man besetzen könnte, so dass ich in Unterfunktionen
sowas machen wie

Delphi-Quellcode:

if (TThread.CurrentThread.CheckTerminated()) then DoContinue := False;

?
Oer kann ich dem Rest-Request irgendwie sagen

Delphi-Quellcode:

restRequest.CancelOnThreadTerminated := True;

?
Für Ideen und Tipps wäre ich sehr dankbar!

Mit freundlichem Gruß
Incocnito

Mein erster Gedanke wäre den Thread mittels einem Event zu kontrollieren und sobald dies gesetzt ist, diesen zu beenden:

Delphi-Quellcode:

constructor TBThread.Create;
begin
  inherited Create(true);
  FTerminateEvent := CreateEvent(nil, true, False, nil);
end;

destructor TBThread.Destroy;
begin
  SetEvent(FTerminateEvent);
  CloseHandle(FTerminateEvent);
  inherited;
end;

procedure TBThread.Execute;
begin
  while not Terminated do
  begin
      if WaitForSingleObject(FTerminateEvent, fcint) = WAIT_TIMEOUT then
    begin
      if not Terminated then
        DoSomething;
    end;
  end;
end;

procedure TBThread.TerminatedSet;
begin
  inherited;
  SetEvent(FTerminateEvent);
end;

[TiGü]

Musst du dir denn einen eigenen Thread bauen?
Kannst du nicht das TCustomRESTRequest.ExecuteAsync nutzen und für das Abbrechen das dafür vorgesehene Cancel?

Delphi-Quellcode:

procedure TForm3.FormClick(Sender: TObject);
var
    RESTThread: TRESTExecutionThread;
begin
    RESTThread := RESTRequest1.ExecuteAsync({Bitte hier die optionalen Argumente beachten wie CompletionHandler und CompletionHandlerWithError});

    // Bla blupp, dauert alles zu lange:
    if Assigned(RESTThread) then
        RESTThread.Cancel;
end;

[DeddyH]

Der Beschreibung nach handelt es sich nicht um REST, sondern eher um WebSockets oder ähnliches. Ein REST-Server sendet keine Daten an verbundene Clients (ausgenommen natürlich die explizit angeforderten), allein schon deshalb, weil es keine ständigen Verbindungen gibt.

[Olli73]

Zitat:

Zitat von Klaus01 (Beitrag 1491677)

.. wenn ein Client mit einem Server verbunden ist
und der Server dem Client etwas schickt, dann wird in der Regel
auf dem Client ein Event ausgelöst, da muss man den Server nicht
ewig pollen und schauen ob Nachrichten für den Client da sind.

HTTP(S) ist zustandslos. Der Server kann immer nur auf eine Anfrage des Clients antworten, er kann NICHT von sich aus dem Client etwas senden!

[Olli73]

Zitat:

Zitat von DeddyH (Beitrag 1491683)

Der Beschreibung nach handelt es sich nicht um REST, sondern eher um WebSockets oder ähnliches. Ein REST-Server sendet keine Daten an verbundene Clients (ausgenommen natürlich die explizit angeforderten), allein schon deshalb, weil es keine ständigen Verbindungen gibt.

Websockets wäre die bessere und modernere Technik. Aber er nutzt halt "long polling" als Alternative.

[Incocnito]

Zitat:

Zitat von TiGü (Beitrag 1491680)

Musst du dir denn einen eigenen Thread bauen?
Kannst du nicht das TCustomRESTRequest.ExecuteAsync nutzen und für das Abbrechen das dafür vorgesehene Cancel?

Delphi-Quellcode:

procedure TForm3.FormClick(Sender: TObject);
var
    RESTThread: TRESTExecutionThread;
begin
    RESTThread := RESTRequest1.ExecuteAsync({Bitte hier die optionalen Argumente beachten wie CompletionHandler und CompletionHandlerWithError});

    // Bla blupp, dauert alles zu lange:
    if Assigned(RESTThread) then
        RESTThread.Cancel;
end;

Interessanter Ansatz, hat aber letztlich nicht so geil geklappt.

Delphi-Quellcode:

  ...
  tempThread := Whatever();

  // Speichern der lokalen Objekte, damit man beim OnAccept oder OnError
  // auch damit arbeiten kann:
  mainThread   := tempThread;
  mainClient   := tempClient;
  mainRequest  := tempRequest;
  mainResponse := tempResponse;

  // Warten, bis entweder der Thread von außen beendet wird (Terminated) oder
  // er selbst fertig wird (FRecieved):
  while (NOT Terminated) AND (NOT FRecieved) do
  begin
    Sleep(10);
  end;
  // Wenn hier angekommen schauen, ob er hier ankommt, weil er Daten
  // empfangen hat. Falls es durch "Terminate" von außen passiert ist
  // den Rest-Thread mit "Cancel();" abbrechen:
  if (Terminated) AND (NOT FRecieved) then mainThread.Cancel();

  // Warten, bis er den Thread ordnungsgemäß beendet hat:
  mainThread.WaitFor();

  // Jetzt sind wir hier fertig, das Programm soll beendet werden,
  // also alles wieder freigeben:
  mainClient.Free();
  mainRequest.Free();
  mainResponse.Free();
  mainThread.Free();

Beim Freigeben kommt es immer zu Fehlern. Es sieht auch nicht so aus,
als ob Cancel die Rest-Abfrage tatsächlich abbrechen würde,
respektive das WaitFor dann wartet, bis der Abbruch durch ist.

[TiGü]

Das ist mir Zuviel Pseudocode und Zuwenig Kontext, um irgendwas sinnvolles dazu sagen zu können.
Wer ist denn der Owner von Request, Response und Client?
Kannst du dein Problem vielleicht in einen vollständigen kleinen Beispiel zip-archivieren und hochladen?

Vergesse das mal mit dem eigenen Extra-Thread.
Speichere dir den TRESTExecutionThread in eine Member-Variable und prüfe dem Empfang einfach zyklisch per TTimer.
Wenn Antwort empfangen wurde oder das Programm beendet wird, mit Cancel() abbrechen.

[Olli73]

Kannst du nicht einfach einen zweiten Request schicken und der Server beendet (beantwortet) dann auch den anderen Request?

[Incocnito]

Zitat:

Zitat von TiGü (Beitrag 1491733)

Das ist mir Zuviel Pseudocode und Zuwenig Kontext, um irgendwas sinnvolles dazu sagen zu können.
Wer ist denn der Owner von Request, Response und Client?
Kannst du dein Problem vielleicht in einen vollständigen kleinen Beispiel zip-archivieren und hochladen?

Vergesse das mal mit dem eigenen Extra-Thread.
Speichere dir den TRESTExecutionThread in eine Member-Variable und prüfe dem Empfang einfach zyklisch per TTimer.
Wenn Antwort empfangen wurde oder das Programm beendet wird, mit Cancel() abbrechen.

Owner?
RESTClient := TRESTClient.Create(sUrl);
RESTResponse := TRESTResponse.Create(RESTClient);
RESTRequest := TRESTRequest.Create(RESTClient);
Wo gibt es da Owner?

Beispiel hochladen kann ich (wie immer) nicht, da ich mich auf einen Rest-Endpunkt beziehe,
welcher bei euch nicht existiert; Body, Parameter, Header usw. enthalten sicherheitskritische Informationen, welche ich nicht posten kann.

Die Thread-Struktur enthält ja nur diese 3 (für dieses Beispiel relevante):
- Der Main-Thread welcher den Nachrichten-Tread erstellt und beim Close per
"Terminate();" beenden soll
- Der Nachrichten-Thread, welcher den Rest-Thread (wie von TiGü beschrieben) erstellt,
die Events empfangen und Nachrichten abarbeiten soll (ohne den Anwender von der Arbeit ab zu halten)
- Und der Rest-Thread, welcher ja ohnehin durch
RestThread := RESTRequest.ExecuteAsync(aCompletionHandler, False, False, aCompletionHandler2);
erstellt wird (evtl. noch weitere innen-liegende, aber davon habe ich keine Ahnung)

Auf jeden Fall kann ich davon keinen "auflösen". Die Abarbeitung der Nachrichten kann ich ja unmöglich im Main-Thread machen.

Einen Abbruch-Request? Mal sehen, ob das so geht.

Das klingt jetzt alles ein wenig negativ, hoffenlich kommt das nicht falsch rüber.

Ich forsche dann mal weiter ...

LG Incocnito

[TiGü]

Okay, du nimmst TCustomRESTClient.Create(const ABaseApiURL: string); als Constructor, kannte ich so auch noch nicht.

Der Client hat dann keinen Owner und muss selber freigeben werden.
Wenn du aber dann noch Response und Request so erstellst, dass der Client der Owner ist (Übergabe im Constructor), dann kannst du die nicht händisch freigeben.
Daher resultieren wahrscheinlich deine "Beim Freigeben kommt es immer zu Fehlern."-Probleme.

Edit: Den REST-Thread auch nicht selber freigeben, einfach AFreeThread als dritten Parameter im ExecuteAsync() auf True setzen.

[Incocnito]

Ok,

nächster Step ...
Ich habe den TRestExecutionThread wieder raus geworfen und auf einen "normalen" TRestClient-Aufruf umgebaut. Das

Delphi-Quellcode:

RestRequext.Execute();

läuft in einem Thread (der Nachrichten-Thread), wie beschrieben.
Den Thread kann man ja per

Delphi-Quellcode:

Terminate();

beenden.
Nun habe ich die Funktion "TerminateSet" von TThread überladen und dort einfach

Delphi-Quellcode:

RESTRequest.Cancel();

aufgerufen.
Oh Wunder, damit bricht er den Request ab und kommt sauber zurück.
Derzeit gebe ich dann wie von TiGü empfohlen nur den RESTClient frei,
aber ich will noch prüfen, ob ich jetzt irgendwelche Speicherlecks habe.
Damit sieht es auf jeden Fall schonmal gut aus.

Am Ende des Tages wusste ich nicht, dass es "TerminateSet();" und "RESTRequest.Cancel();" gibt.

Ich hoffe das hilft einem eventuellen Leser in Zukunft weiter.

Liebe Grüße
Incocnito