Stabilität einer INDY 10 Anwendung

[bernhard_LA]

wir haben eine INDY 10 TCP Client Server Anwendung entwickelt. Zum debuggen nehmen wir MADSHI.
Die Anwendung basiert auf meinen INDY 10 demos auf http://sourceforge.net/projects/indy10clieservr/. In der Anwendung übertragen zwischen Server und Clients STREAMS, Files, Generische Records.... funktioniert alles fast wunderbar.

Um die Ausgabe von Informationen aus der Procedure tcpserver.execute (...) Threadsafe zu implementieren verwenden wir auch ganz brav TIDSync, bzw. TIDNotify. Unser TCP Server bearbeitet eine recht komplexe Klasse. Um auch hier Zugriffe auf seine interne Bitmap Threadsafe zu gestalten haben wir alle Canvas Operationen mit Lock / Unlock hoffentlich korrekt THreadsafe implementiert
( http://qc.embarcadero.com/wc/qcmain.aspx?d=55871 )

Im Testbetrieb können wir den Server tagelang fehlerfrei betreiben, wir haben 32.000 Tcp server / Client Kommunicationen in diesem Zeitraum. Alles wunderbar.

Wenn wir nun Madshi aus der Anwendung für den Software Release entfernen kommt es schon ab 5 vielleicht auch erst bei 100 oder 300 Kommunikationen zwischen Client und Server zu einem Programmabbruch.



Wie finde ich diesen Fehler , Wie soll ich ohne Madshi debuggen, Wo kann denn dieser Fehler liegen

[SvB]

Meinst Du madExcept? Oder was genau benutzt Du von Madshi zum debuggen?

[mjustin]

Wie sieht denn dieser Programmabbruch aus?

[bernhard_LA]

ja, ich verwende Madexcept von Madshi http://madshi.net/

mein Client wartet auf eine Antwort vom Server und steht irgendwo... der Server bricht auch irgendwo ab .... , auffallend ist der VCL Update hat nicht mehr geklappt es steht nur noch der halbe Text in meiner Statuszeile

[mjustin]

und wenn das VCL Update ausgeschaltet ist, funktioniert es?
als erstes würde ichlogging einbauen, zum beispiel mit log4d, und damit die kritische stelle eingrenzen, wenn debugging xschwierig ist.

[Aphton]

Zitat von bernhard_LA:

(...) auffallend ist der VCL Update hat nicht mehr geklappt es steht nur noch der halbe Text in meiner Statuszeile

Wie genau meinst du das? Wird der Text empfangen?

[SvB]

madExcept ist aber doch kein debugging Tool. Es hilft doch viel mehr analysieren von Exception, in dem es mehr Information raus gibt, als man normalerweise erhält.
Ich lasse madExcept immer im Programm drin.

[mjustin]

Zitat von SvB:

madExcept ist aber doch kein debugging Tool. Es hilft doch viel mehr analysieren von Exception, in dem es mehr Information raus gibt, als man normalerweise erhält.

madExcept soll ja eigentlich, in der Basiskonfiguration, nur die unbehandelten Exceptions abfangen.

Wenn madExcept aber das Programmverhalten (negativ oder positiv) verändert, ist etwas im Programm nicht in Ordnung.

Ich würde testweise madExcept einmal so zu konfigurieren, dass es nur noch das Exceptionhandling übernimmt und alle optionalen, "fortgeschritteneren" Funktionen und Features (Erkennen eingefrorener Anwendungen usw.) abschalten. Dann den Test nochmal wiederholen. Vielleicht kann man durch ein "Ausschlussverfahren" herausfinden, welches madExcept Feature die stabilere Arbeitsweise bewirkt.

[geskill]

Hey,
werden mit der Komponente möglicherweise mehrere Verbindungen zur exakt gleichen Zeit geführt. Also in Millisekunde xyz ein Update-Check und xyz ein Anwendungsrequest "whatever"?

Indy benutzt blockierende Sockets.

Ich habe festgestellt, dass in einem Programm mit vielen Verbindungen (zur exakt gleichen Zeit) dies zwangsläufig zu Problemen führt. Entweder musst du dies komplett Kontrolliert ausführen (mit maximal einer Verbindung zur gleichen Zeit) oder du benutzt ICS, welche nicht blockierend arbeitet.

Diese Erfahrung habe ich jedenfalls gemacht :/

Grüße

[mjustin]

Zitat von geskill:

Indy benutzt blockierende Sockets.

Ich habe festgestellt, dass in einem Programm mit vielen Verbindungen (zur exakt gleichen Zeit) dies zwangsläufig zu Problemen führt. Entweder musst du dies komplett Kontrolliert ausführen (mit maximal einer Verbindung zur gleichen Zeit) oder du benutzt ICS, welche nicht blockierend arbeitet.

Diese Erfahrung habe ich jedenfalls gemacht :/

Konkurrierender Zugriff auf einen Socket kann nur in einer Multithreading Anwendung gut gehen.

Es liegt nicht am blockierenden Zugriff, falls Indy bei vielen Verbindungen "Probleme" macht, sondern meist an Fehlern im Code, vor allem bei der Kommunikation mit dem Hauptthread der VCL geschieht das gern.

Auch das Betriebssystem spielt eine Rolle, zum Beispiel wenn die Socket-Verbindungen nicht wiederverwendet werden, sondern der Client immer wieder neue Sockets öffnet und schliesst. Die geschlossenen Sockets bleiben dann für einige Zeit in Warteposition (Status TIME_WAIT), und das System wird sehr schnell überlastet. Das kann man mit netstat oder TCPView leicht nachvollziehen.

Jede Indy Client Komponente baut ihre eigene TCP Verbindung über einen eigenen Socket auf. Bei einem Indy Server gibt es für jede Verbindung einen separaten Thread, und jeder Socket wird immer nur von einem Thread bedient.