TIdHTTPServer: Programmabsturz bei langwieriger ResponseInfo-Berechnung

[MStoll]

Das try...finally ist weniger der Exceptions wegen (die erwarte ich im try-Block nicht), sondern dazu, dass ich im try-Block ein exit ausführen kann, wenn ich weiter innen mit dem Aufstellen der Antwort fertig bin. Kann man auch anders lösen, muss man aber nicht.

Im übrigen ist das ein Beispiel-Code, um zu zeigen, wo das Sleep platziert ist, und nicht etwa der Code im Endzustand. Da müsste auch noch ein try...except, um den Block, der den ContentText behandelt herum, um konsistent zu sein. Aber der beschriebene Fehler tritt in erster Linie im ContentStream-Block auf.

Und ich habe nicht gesagt, dass ich das gleiche Frame jedesmal in JPEG umwandle. Aber wenn alle Clients während der 2-3 Sekunden, in denen die Umwandlung zum ersten und einzigen Mal stattfindet, anfragen, dann müssen sie halt auch alle warten, bis die erste Erstellung vorbei ist. Und dieses Warten ist, wie gesagt, so gewollt. Danach wird bis zum Zwischenspeichern eines anderen Frames aus einem Cache, der die JPEG-Variante enthält, gelesen.

Und nochmal: ich habe hier das recht _allgemeine_ Problem, dass bei einer langen Antwortberechnung (egal wie die jetzt im Detail aussieht, ob ContentText oder ContentStream benutzt wird etc.) das Programm _kommentarlos_ abstürzt.

Ich bin dankbar für eure Mühen.
Aber ich bin kein Anfänger, dem man die Grundlagen des Exception-Handlings erklären muss, NUR weil in dem unfertigen Beispiel-Stück vielleicht das eine oder andere Detail noch nicht ganz perfekt aussieht. Das Problem liegt hier an einer anderen Stelle, soweit bin ich schon gekommen. Mein Problem ist, dass ich den detaillierten Aufbau des Indy HTTP-Servers nicht kenne und mir das Programm mangels Fehlermeldung auch keinerlei Hinweis darauf gibt, wo das Problem sein könnte (trotz try...except-Block um die betreffende Stelle).
Und sollte es da irgendwo eine Zugriffsverletzung geben, dann weiß ich nicht, wie das Programm auf derartige Exceptions reagiert. Da habe ich schon unterschiedlichste Erfahrungen gemacht, je nach dem, ob solche Exceptions in eingebundenen Laufzeitbibliotheken (statisch oder dynamisch eingebunden) oder im Hauptprogramm, im Main-Thread oder einem Hintergrund-Thread auftreten. Die Bandbreite reicht von Exception mit Fehlermeldung, über Fehlermeldungen mit Programmabsturz, Einfrieren des Programms bis hin zum kommentarlosen verschwinden. Und das alles auch, wenn der entsprechende Teil mit einem try...except-Block geschützt war. Evtl. räumt ja der Indy HTTP-Server irgendwo nach einem Timeout was auf, was noch nicht aufgeräumt werden sollte.

Ich werde jetzt mal einen try...except-Block um das ganze Programm machen, in der Hoffnung, irgendwas zu finden. Da es sich allerdings um einen Server handelt und der Fehler beim Senden der Antwort liegt, weiß ich nicht, ob der try...except-Block dann den richtigen Thread "umfasst".

[MStoll]

Update: auch ein try...except-Konstrukt, in dem der Exception-Block die Exception-Nachricht ausgibt, um das Haupt-Programm ändert nichts am kommentarlosen Absturz.

[Mavarik]

Zitat von MStoll:

Update: auch ein try...except-Konstrukt, in dem der Exception-Block die Exception-Nachricht ausgibt, um das Haupt-Programm ändert nichts am kommentarlosen Absturz.

Ich "glaube" nicht an ein Zeitverhalten...

Kann es sein, dass dir irgend etwas durch den Speicher rauscht?

Mavarik

[MStoll]

@Mavarik:
Ich weiß nicht, was mir durch den Speicher rauschen sollte. Ich erstelle einen MemoryStream in der Variable AResponseInfo.ContentStream, befülle ihn mit Daten (JPEG-Bild) und erwarte dann, dass sich der Indy HTTP-Server um den Rest kümmert. Was ja auch, wenn es schnell genug geht, immer klappt. Viel mehr mache ich nicht.

@himitsu:
Stimmt, den exit-Code könnte ich mir mal noch anschauen. Hast du eine Idee, wie das möglichst einfach geht? Mit denen habe ich mich bisher noch nicht befasst.

Ich schaue mir gerade mal noch die TerminateWaitTime-Eigenschaft der TIdCustomTCPServer-Klasse an. Eventuell hat die Einfluss auf das Verhalten.

[MStoll]

Ich habe gerade mal die DoCommandGet-Methode des HTTP-Servers "vereinfacht":

Delphi-Quellcode:

procedure THTTPServer.DoCommandGet(AContext: TIdContext;
      ARequestInfo: TIdHTTPRequestInfo;
      AResponseInfo: TIdHTTPResponseInfo);
begin
  AResponseInfo.ContentText := 'Test';
  Sleep(4000);
end;

Das reicht, um bei ein paar Client-Verbindungen das Programm zum Absturz zu bringen... leider....

[mjustin]

Zitat von MStoll:

Ich schaue mir gerade mal noch die TerminateWaitTime-Eigenschaft der TIdCustomTCPServer-Klasse an. Eventuell hat die Einfluss auf das Verhalten.

TerminateWaitTime kommt nur ins Spiel, wenn der Server kontrolliert beendet wird. Es legt fest, wie viel Zeit der Server insgesamt den Context-Threads läßt, um "herunterzufahren". Aus der Onlinehilfe für Indy:

Zitat:

TerminateWaitTime is an Integer property that identifies the total number of milliseconds that the server should wait while terminating the executable tasks for client connections. TerminateWaitTime is an aggregate delay time used while monitoring the thread list in Contexts during server shutdown. The length of the Contexts thread list is checked every 250ms until TerminateWaitTime has elapsed, or the length of the list is 0 (zero). If the value in TerminateWaitTime is exceeded before the length of Contexts reaches 0 (zero), an exception is raised.

[viper3001]

Habe ebenfalls genau das selbe problem. Unter debian sorgt ein zu lange andauernder response für einen direkten crash ohne Informationen, wobei unter windows ein socketerror #10053 erzeugt wird und das programm normal weiter läuft.

Beides wurde mit Lazarus auf Windows und auch auf Debian getestet.


MfG

Nachtrag: hab die .exe per wine laufen lassen und diese variante läuft ohne crash auf debian...

[himitsu]

Das spricht dann wohl doch für einen Bug im Linux oder Lazarus/FPC/Indy.

Wobei ich jetzt mal den Bug eher in Lazarus/FPC/Indy suchen würde, als im Linux, denn ein Timeout sollte ja nicht so selten sein und in den letzten paar Jahren sollte das schon aufgefallen sein, also vorallem in den anderen Programmiersprachen, die vermutlich häufiger verwendet wurden.

[mjustin]

Ist es möglich ein kleines Beispielprojekt - Client und Server - hier zu posten (Client und Server), um das Problem zu reproduzieren? (meine Umgebung: Lazarus oder Delphi 2009 und neuer, Indy 10.6, Windows 8, oder Ubuntu 12.04).

[MStoll]

Das müsste so reichen:

Delphi-Quellcode:

unit http;

{$mode objfpc}{$H+}

interface 

uses
  Classes, SysUtils,

  IdHTTPServer, IdCustomHTTPServer, IdContext, IdSocketHandle, IdGlobal;

type
  THTTPServer = class(TIdHTTPServer)
  private
    _newPort : Word; 
  public
    constructor Create(port : Word);
    procedure InitComponent; override;
    procedure DoCommandGet(AContext: TIdContext;
      ARequestInfo: TIdHTTPRequestInfo;
      AResponseInfo: TIdHTTPResponseInfo); override; 
  end;

implementation

constructor THTTPServer.Create(port: Word);
begin
  _newPort := port;

  inherited Create;
end;    

procedure THTTPServer.InitComponent;
var
  Binding: TIdSocketHandle;
begin
  inherited;

  Bindings.Clear;
  Binding := Bindings.Add;
  Binding.IP := '0.0.0.0';
  Binding.Port := _newPort;
  Binding.IPVersion := Id_IPv4;
end;

procedure THTTPServer.DoCommandGet(AContext: TIdContext;
      ARequestInfo: TIdHTTPRequestInfo;
      AResponseInfo: TIdHTTPResponseInfo);
begin
  AResponseInfo.ContentText := 'Test';
  Sleep(4000);
end;

end.

Als Client habe ich Google Chrome verwendet (mit ein paar Tabs, die den Webserver anfragen). Aber auch jeder andere Browser sollte es tun. Spätestens, wenn du in den Tabs schnell ein paar mal F5 drückst, sollte das Server-Programm abstürzen.

Ich bin mittlerweile bei Synapse. Damit scheint das ganze zu funktionieren (erste Einschätzung).