DataSnap Client connection über FireDAC

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1269624)

Zitat:

Zitat von Uwe Raabe (Beitrag 1269596)

Erganzend dazu: Der ClientCallbackManager braucht einen kleinen Patch, damit er nach einem Verbindungsabbruch wieder funktioniert.

Welchen meinst du?

Callbacks habe ich zumindest aus Thin Clients durch erneute Verbindungsversuche wiederherstellen können ohne dass ich etwas geändert hätte.

Den Patch brauchte ich in einer XE3 App und ich habe es unter XE6 noch nicht wieder probiert, denke aber es ist dort immer noch so.

Kurz: Bei verbundenem Client den Server neu starten. Nun funktionieren die Callbacks nicht mehr und der Client kann die auch nicht mehr registrieren. Das lässt sich nur mit einem Neustart des Clients beheben (genauer mit dem Neuerzeugen des CallbackManagers).

Lang: In TDSClientCallbackChannelManager.CloseClientChannel wird das interne Feld FStopped gesetzt, wenn der Server die Verbindung beendet. Dabei werden aber die Callbacks nicht freigegeben. Ruft man dann TDSClientCallbackChannelManager.CloseClientChannel auf, ist der ExcuteRemote-Aufruf zum einen vollkommen überflüssig (die Verbindung ist ja definitiv weg) und läuft zum anderen in einen Timeout (kostet unnütz Zeit). Das nachfolgende FLocalCallbackRepo.Clear und das Anpassen der Statevariablen wird nicht mehr aufgerufen. Die Callbacks bleiben also im Dictionary und man kann Sie somit nicht mehr neu anlegen (RegisterCallback sieht, die sind schon da und gibt false zurück). Die alten Callbacks funktionieren aber nicht mehr, weil sie beim Server nicht mehr registriert sind (der wurde ja neu gestartet).

Der Patch besteht im Wesentlichen darin, bei FStopped das ExecuteRemote zu überspringen und trotzdem das FLocalCallbackRepo.Clear aufzurufen. Bei XE3 liegt der Code in Datasnap.DSHTTPCommon und bei XE6 in Datasnap.DSCommon.

[jaenicke]

FStopped finde ich nicht, ich vermute du meinst State auf Stopped? Das Problem ist dann aber klar, ja.
Der Code in CloseClientChannel sieht in XE3 und XE6 identisch aus.

Jetzt wo du es sagst, kann ich mich auch erinnern, dass ich an der Stelle schon einmal ein Problem hatte, ich hatte es mir nur nicht genauer angeschaut.

Gibt es dazu schon einen QC Eintrag? Ich konnte nämlich eben bei einer schnellen Suche keinen finden.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1269634)

FStopped finde ich nicht, ich vermute du meinst State auf Stopped?

FStopped ist ein Feld von TDSClientCallbackChannelManager und wird in NotifyChange gesetzt. Da es strict private ist, lässt sich das leider auch nicht mit einer abgeleiteten Klasse fixen.

Zitat:

Zitat von jaenicke (Beitrag 1269634)

Der Code in CloseClientChannel sieht in XE3 und XE6 identisch aus.

Bis auf die Tatsache, daß in XE3 die lokale Variable Status nicht initialisiert wird und damit einen unbestimmten Wert enthält wenn State <> ctsStarted ist. In XE6 wird sie mit False vorbelegt, was meiner Meinung nach ungünstig ist, aber das ist vielleicht auch Geschmackssache. Ich finde es intuitiver, wenn auch bei State <> ctsStarted ein CloseClientChannel mit true durchläuft und der State hinterher auf ctsStopped steht, insbesondere wenn der State vorher auf ctsFailed stand. Wichtig ist aber, daß Status bei FStopped auf True gesetzt wird, damit auch aufgeräumt wird.

Zitat:

Zitat von jaenicke (Beitrag 1269634)

Das Problem ist dann aber klar, ja.Gibt es dazu schon einen QC Eintrag? Ich konnte nämlich eben bei einer schnellen Suche keinen finden.

:oops: Ich muss zu meiner Schande gestehen, daß ich es versäumt habe, einen simplen Testfall aufzubereiten. Takahashi san ist da bekannterweise etwas anspruchsvoll. Ich gelobe aber Besserung.