Long running Rest API Call mit THTTPClient

[Christoph Schneider]

Mit einem eigenen Prozess wäre zwar das Memory Leak entschärft, dafür müsste eine Interprozesskommunikation (bpsw. mit einer Pipe) alle eintreffenden Meldungen an den startenden Prozess übermitteln. Da erscheint mir der Aufwand zum Ertrag (keine aufsummierenden Memory Leaks mehr) gar etwas hoch. Beide Lösungen (Thread Kill vs. Prozess Kill) sind ein Murks.

Aus meiner Sicht müsste es wenigstens auf Api Level möglich sein, ein gestarter HTTP Request vom aufrufenden Thread in allen Fällen (also auch ohne Empfang von Daten) jederzeit wieder zu stoppen.
Ich glaube, ich schaue jetzt mal wie das unter Windows gemacht werden könnte.

Danke für die vielen wertvollen Ideen.

[TiGü]

Hast du ein Beispiel für eine öffentliche REST-Schnittstelle mit long running requests?
Meine bisherigen Erfahrungen mit REST habe ich nur mit Schnittstellen gemacht, die innerhalb von einer handvoll Sekunden geantwortet haben.

[Christoph Schneider]

Ja, ich beschäftige mich im Moment mit der Anbindung von der Google Firebase Realtime DB. Dort werden Long running Rest API Calls für Server Events eingesetzt.

Details gibt es hier:
https://firebase.google.com/docs/ref...tion-streaming

Ich bin mir am überlegen, ob ich meine Library für Firebase/Firestore und Google-Storage nach Fertigstellung als Open-Source Projekt auf Git verfübar machen soll.
Wer Interesse am Thema hat, darf sich gerne bei mir melden.

[Rollo62]

Gemeldet

[TiGü]

Ich muss nochmal simpel nachfragen:

Ein Aufruf von ExecuteAsync von dem TRESTRequest genügt deinen Anforderungen nicht?

Delphi-Quellcode:

var
  CompletionHandler: TProc;
  MyThread: TRESTExecutionThread;
begin
  CompletionHandler := procedure
    begin
      Memo1.Lines.Add(RESTResponse1.Content);
    end;

  MyThread := RESTRequest1.ExecuteAsync(CompletionHandler, True, False);
  //
  //  ... irgendwas machen...
  //
  MyThread.Free;

[Christoph Schneider]

Ich fand leider noch keine Zeit TRESTExecutionThread mal in dieser Situation auszuprobieren.
Aus meiner Sicht liegt die Ursache aber im zugrunde liegenden HTTP-Request der im Betriebssystem hängt, wenn keine Daten empfangen werden. Die THTTPRequest-Klasse hat diesen Fall vermutlich schlicht nicht vorgesehen, denn mit kurzen Timeouts läuft diese Situation im Regelfall ja gut. Ich müsste vermutlich ein Cancel auf das Handle (HINTERNET) von Request machen können.

[Christoph Schneider]

Ich habe heute zu diesem Fall einen Eintrag in der Quality-Zentrale von Embarcadero vorgenommen:
https://quality.embarcadero.com/browse/RSP-20827