DataSnap - Connection-Probleme

[himitsu]

Soooo,

ich hab mir einen DSServer erstellt, dann über den Assistenten mir die ClientKlasse und das ClientModul erstellen lassen.

Wenn jetzt der Server abschmiert oder einfach nur ganz "normal" über Server.Stop deaktiviert wird, dann bekommen die Clienten das nicht mit.
OnDisconnect wird nicht aufgerufen, SQLConnection1.Connected steht weiterhin auf True.

Sobald nun eine Servermedode ausführe, egal ob vorher die Connection manuell mit

Delphi-Quellcode:

ClientModule1.SQLConnection1.Connected := False;
ClientModule1.SQLConnection1.Connected := True;

neu aufgebaut wird, knallen nun alle Aufrufe der Servermethoden, egal ob das TDBXCommand schon exisitert (Methode schonmal aufgerufen) oder neu erstellt wird (Methode wurde vorher noch nicht aufgerufen).


Hab ich jetzt irgendeinen Fehler reingebaut? (außer ein zusätliches Logging der Events hab ich aber nix Schlimmes eingebaut)
Kennt jemand das Problem und hat vielleicht eine Lösung?


Nach einem Verbindungsabbruch kommt dann immer du Folgender Exception, beim internen Aufruf von XyzCommant.Prepare, bzw bei XyzCommant.ExecuteUpdate.

Zitat:

---------------------------
Clientproject
---------------------------
Socket-Fehler # 10053

Software verursachte einen Verbindungsabbruch.
---------------------------
OK
---------------------------

Knallte es vorher im XyzCommant.Prepare, dann rumst es nachher schon beim Zuweisen der Parameter, vorm ExecuteUpdate.

Zitat:

---------------------------
Clientproject
---------------------------
Ungültige Ordinalzahl: 0.
---------------------------
OK
---------------------------

Weder Server noch Clienten bekommen mit, wenn die Connection abbricht.
Auf Seiten des Server ergibt das dann nette Speicherlecks, was für einen lange laufenden Service/Server nicht unbedingt optimal ist.


Wir haben auch grade rausbekommen, daß Windows KeepAlive-Connections lange nicht schließt, da es garnicht oder nur selten die Verbindung prüft.



Wir versuchen grade unseren AppServer neu aufzubauen, nachdem wir nun genügend mit DataSnap rumgespielt haben
und mit massenhaft Problemchen (Bugs und Dokumentationsfehler) konfrontiert sind.

Uns sind auch mal dabei das Teil (DataSnap) auf Herz und Nieren zu testen, bzw. zu schauen was der wie wo macht.
- wieviele Connections gibt es
- wie ist die Verbindungssicherheit
- wie die Verbindungsstabilität
- ...
- und vorallem ... wie reagiert das Teil bei Problemen




PS: Callbacks, sind wegen der Connectionprobleme nicht nutzbar ... ich hatte grade einen Test, da gehen durchschnittlich 5-90% der BroadcastMessages einfach so verloren.
Abgesehn davon, daß wir die eh nicht nutzen könnten, da sie sich, Aufgrund eines eklatanten Designfehlers, nicht mit einer Connections-Authentifizierung vertragen. (man kann Clientseitig nirgendwo Benutzername und Passwort angeben).

[jaenicke]

Bei XE mache ich das bisher so, dass ich den Verbindungsabbruch an genau dieser Exception erkenne und behandle. Damit das möglichst zeitnah passiert, schicke ich bei Inaktivität Keep-Alive-Anfragen.

Ab XE2 gibt es direkte Events, die auf Verbindungsabbrüche reagieren, siehe die aktualisierte Demo unter:

Code:

Users\Public\Documents\RAD Studio\9.0\Samples\Delphi\DataSnap\CallbackChannels

[himitsu]

Manuelle Keep-Alive-Anfragen wären nicht das Problem, aber das Problem ist, daß der DSClient, sowie der DSServer die Connections dann nicht richtig schließt, womit die damit zusammenhängenden Klassen nicht freigegeben werden (Speicherlecks) und der Server hat auch noch ein Problem, da er beim Shutdown nochmal (automatisch) mit allen "registrierten" Callbacks Verbindung aufnimmt, um denen zu sagen "so, ich geh dann mal, wäre gut, wenn du dich deaktivierst ... oder so".


Wenn man mit den automatisch generierten Klassen arbeiten will (in unserem alten/aktuellen AppServer hab ich eigentlich alles selber gemacht und die Generatoren gemieden), und nicht bei jeder Änderung seine "bugfixes" neu einbauen will,

dann hab ich bis jetzt nur eine "praktikable" Lösung entdeckt:

- keine (verbuggten) Callbacks .. stattdessen regelmäßiges Pollen (wie gesagt, dank einer Authentifizierung eh nicht nutzbar)

- das komplette Servermodul wird manuell erstellt
und zwar vor einem jeden Methodenaufruf und danach wird sofort die Verbindung wieder freigegeben, also das komplette Datenmodul freigegeben, da ein Reconnect nach einem Verbindungsabbruch nicht correkt möglich ist, außerdem ist, dank der kurzen Verbindungen, die Chance geringer, daß eine Verbindung abbricht, was den Server stabiler laufen läßt.

Es sei denn man baut eben die automatisch generierten Clientklassen jedes Mal um > disconnect in (nach) jedem Methodenaufruf und die ClientMethodenKlassen werden vor jedem Aufruf neu erstellt.



Und das war bis jetzt die einzigeste Möglichkeit, damit Server und Client über lange Zeit / viele Aufrufe stabil läuft.





Und ja, wir sind seit letzer Woche dran, alle möglichen (uns auch nur im Traum einfallenden) Szenarien durchzuspielen, um die Funktion irgendwie zu stören, um möglichst Alles zu testen.
Wir haben halt in unserem großen AppServer immer wieder "unerklärliche" Problem.

Ist schon witzig, daß von 10000 schnell aufgerufenen leichtgewichtigen Heavyweight Callbacks "nur" 9500 ankommen ... je mehr Clienten, um so mehr verschwindet und irgendwann verabschieden sich sogar die Callbckverbindungen still und heimlich (kommt nix mehr an, obwohl angeblich aktiv).









Ach ja, das gesammte Projekt auf XE2 umszustellen kommt aktuell nicht in Frage.
Wir haben jetzt schon fast ein Jahr benötigt, um von D7 auf XE umzustellen, dazu noch den alten (komplett selbstbebastelten) Apps auf DataSnap und es läuft immernoch nicht alles ordnungsgemäß.

Erkläre jetzt mal den Kunden: Tut uns leid, aber das nächste halbe Jahr wird wieder nix, da wir nochmal alles umstellen.