TIdHTTPServer: Programmabsturz bei langwieriger ResponseInfo-Berechnung

[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....:(

[Furtbichler]

Was passiert eigentlich, wenn Du die Anwendung im Debugger auf einem PC laufen lässt? Wenn irgendwo eine Timeout-Exception während der 2 Sekunden geworfen wird, wird man das doch wohl merken. Indy ist ja bekannt dafür, Exceptions als Flußkontrolle zu verwenden.

Dein Handler wird in einem Thread aufgerufen, hier einen Try-Except-Block zu bauen, ist sicherlich sinnvoll, wird aber das Verhalten des Hauptthreads nicht beeinflussen. Wäre ja denkbar, das der den Thread abschießt, weil er 2 Sekunden lang ackert (was albern wäre, aber denkbar).

Wie weit ist dein Projekt? Kommen andere Komponenten in Betracht? Ich denke an ICS, die sind eventgesteuert, längst nicht so CPU-lastig. Nachteil: Man muss doch einiges an Logik über Events und endliche Automaten selbst lösen.... Hups, ICS wird für FreePascal nicht erhältlich sein (aber vielleicht gehts trotzdem, Source ist ja vorhanden).

[MStoll]

Ich werde das mal mit Debugger auf dem PC testen. Und dort sowohl in einem Konsolen- als auch in einem GUI-Programm.

Aber das erst im nächsten Jahr. Für heute ist's genug.

Allen einen guten Rutsch! :)

[mjustin]

Zitat:

Zitat von MStoll (Beitrag 1241590)

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.

[MStoll]

Schon mal beruhigend, dass ich nicht der einzige bin, der mit dem Problem zu kämpfen hat.

Ich versuch's jetzt mal damit: http://wiki.freepascal.org/Synapse. Evtl. funktioniert das auf dem Raspberry.

[creed steiger]

evtl wäre fcl-web TFPHttpServer eine Alternative
http://opensoft.homeip.net/articles/webserver1.pdf
unter
FPC packages/fcl-web/examples/
solltest du auch fündig werden

[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).