Gelegentliche Hänger

[Bummi]

Wenn ich die ganzen unsynchronisierten Zugriffe auf Komponenten des MainThreads sehe wundere ich mich dass das ganze überhaupt funktioniert....

[Medium]

Wo? Genau das wollte ich doch mittels der Entkopplung durch die Message WM_VCLUPDATE verhindern, dessen Handler doch im Hauptthread-Kontext läuft - oder nicht?

[Bummi]

Du greifst über FForm. so wie ich es verstehe in den Hauptthread, auf welcher Ebene Query und zugehörige Connection hängen kann ich nicht erkennen...

[Medium]

Über FForm greife ich nur auf die CriticalSections sowie auf Listen zu, deren Zugriff über eben diese CriticalSections abgesichert wird. Da wird niemals eine VCL Komponente drüber angefasst, abgesehen von ihrern Referenzen, die in die UpdateItems-Liste gehören. Die Referenzen stammen aber aus einer TObjectList (nicht etwa mit FindComponent), und weiter als den blanken Pointer (und ClassType) geht der Thread nicht. Die Referenzen sollten ja über den gesamten Lebenszeitraum des Formulares konstant bleiben hoffe ich. Es wird zumindest nichts dynamisch erzeugt/zerstört.

Query und Connection liegen im Kontext von TUpdateThread, und werden in dessen Konstruktor erzeugt. (UniDAC).

Ein ähnliches, nur "dümmeres" Verfahren läuft bei einigen Kunden auch schon Störungsfrei seit Monaten. Dort schickt der Server nur keine Updatebenachrichtigungen, sondern der UpdateThread macht ganz naiv jede Sekunde von selber einen vollen Rausch über die Datenbank und updated. Ich wollte das durch die Notifies jetzt nur verschlanken, da das Verfahren sonst in größeren Projekten doch etwas arg auf die Netz- und Rechnerperformance geht.

Meinen Loggingbemühungen nach scheint der wesentliche Knackpunkt das Eintreffen von TCP-Paketen zu sein. Wenn die so schnell kommen, läuft was schief. Wie ist das eigentlich: Wenn ich mit TServerSocket.SendBuf() etwas versende, was auf jeden Fall kleiner ist als ein TCP Payload - bekomme ich dann wirklich im Client ein OnSocketRead pro Server.SendBuf? Oder kann mir es passieren, dass auch mal 2 oder mehr SendBufs an einem Stück im Client eintreffen? Oder gar Fragmente trotz der geringen Größe der Nachrichten?
Nicht, dass ich hier am Ende an der komplett falschen Stelle suche!

[mjustin]

Zitat von Medium:

Wie ist das eigentlich: Wenn ich mit TServerSocket.SendBuf() etwas versende, was auf jeden Fall kleiner ist als ein TCP Payload - bekomme ich dann wirklich im Client ein OnSocketRead pro Server.SendBuf? Oder kann mir es passieren, dass auch mal 2 oder mehr SendBufs an einem Stück im Client eintreffen? Oder gar Fragmente trotz der geringen Größe der Nachrichten?

Vieles ist möglich bei Non-Blocking Sockets - das hat aber weniger mit TCP zu tun als damit, dass die Kommunikation über die Windows Message Loop als Flaschenhals läuft, während blockierende Sockets (Indy, Synapse, und TClientSocket im blocking Modus) diesen Risikofaktor nicht haben.

Daher würde ich versuchen, die (deprecated) ServerSocket und ClientSocket Komponenten auszutauschen, Synapse zum Beispiel ist einfach zu verwenden, solide und performant. Auch ist der Code, den man für blockierende Socketoperationen schreibt, einfacher zu lesen da er sich mehr am Protokoll orientieren kann. In Tests erreiche ich kontinuierlich über 8.000 Nachrichten pro Sekunde zu/von einem in Java geschriebenen Server, der gleichzeitig mit dem Delphi Programm läuft (auf einem Vista-Billiglaptop).

[Medium]

Ich könnt mir in die Furt beißen. Eine einfache Stop-Sequenz im Protokoll mit einem kleinen Empfangspuffer, und aller Spuk ist vorbei. Mit Indy werde ich irgendwie noch nicht so recht warm. Aber dieses einfache Frame um meine Notify-Päckchen wirkte wunder. Mein Thread-Konzept scheint also doch sehr stabil, und die ganze Zeit waren falsch interpretierte Bröckchen vom Server das Problem. Argh
(Nicht, dass mir das grundlegende Problem diesbezüglich unbekannt gewesen wäre, aber aus Faulheit falsche Annahmen treffen geht doch öfter nach hinten los als gewünscht.)

Ich glaube das Thema ist hiermit durch. Danke euch!