orphaned connections

Ich habe erst kürzlich ein Verhalten von Navision bzw. vom SQL Server bemerkt, bei dem die Sessions auf dem SQL Server
(2005) offen bleiben, wenn ein Client abstürzt.

Also habe ich mich diesbezüglich mal im Netz schlau gemacht, und bin auf einen Artikel von Microsoft gestoßen, der die
sogenannten "orphaned connections" beschreibt:
http://support.microsoft.com/kb/137983/en-us
Also habe ich mir sofort mal mit NETSTAT angeschaut, was in diesen Fällen mit den TCP Sessions auf dem Server los ist, und
die bleiben tatsächlich "alive", do dass in der Konsequenz auch die SQL Sessions nicht beendet werden. Und was das wiederum
zur Folge hat, weiß jeder, der schon mal Probleme mit seinen Navision Lizenzen hatte Natürlich weiß ich, wie ich eine
Session "killen" kann, und dann ist auch die TCP connection weg - womit ja alles wieder ok ist.

Überhaupt ist das alles nicht so tragisch, und es passiert auch nur sehr selten, dass es hier einen Client komplett raus haut.
Ich bin eigentlich nur so irritiert, weil ich hätte schwören können, dass das System dieses verhalten früher nicht an den Tag gelegt
hat - oder ist mir das nur nie aufgefallen? Die unter dem MS Link beschriebenen Registry Einstellungen für das KeepAlive konnte ich
allerdings auch noch nicht an der beschriebenen Stelle finden.

Und "leider" gelingt es mir momentan auch nicht, den Client mal gezielt abstürzen zu lassen, obschon mir das beim Report Design
in der Vergangenheit nicht selten passiert ist. Ihr mögt jetzt denken "Hat der sonst keine Sorgen?", aber kennt jemand einen weg,
den Client gezielt abstürzen zu lassen ?

Darüberhinaus würde mich interessieren, ob jemand schon mal beobachtet hat, wie sich andere Systeme diesbezüglich verhalten?

Pidi

[...] kennt jemand einen weg, den Client gezielt abstürzen zu lassen ? [...]

Hallo Pidi,

es gibt keine dummen Fragen, sondern nur dumme Antworten, mit welcher ich dir hier jedoch nicht dienen werde

Folgender Fehler funktioniert bis heute (NAV 6.0 SP1) sehr zuverlässig: (gerade getestet)
(Voraussetzung: Du musst irgendwo (z. B. in einem Report) Zugriff auf den C/AL-Code haben.)
Versuche einfach mit einem RecordRef auf ein Feld von Typ Code <5 Zeichen zuzugreifen.
(Sehr beliebt und daher häufig gesehen: Code[3])
Direkt bei dem Versuch auf das Feld zuzugreifen, schmiert die fin.exe/finsql.exe mit 100%iger Wahrscheinlichkeit ab.

Beispiel:

Code:

RecRef.OPEN(Database::"Sales Header");
IF RecRef.FINDFIRST THEN
  IF FORMAT(RecRef.FIELD(51).VALUE) <> '' THEN;  // <-- Field51 = "On Hold" (Abwarten) = Code[3] = garantierter Absturz

Um einen praktikablen Workaround für euer Problem zu liefern:
Ihr könntet in einer Einrichtungs-Tabelle eine Zeitspanne (Duration) hinterlegen, welche die maximale IDLE-Time definiert.
(Optional könnte dieser Wert auch in der Tabelle User Setup hinterlegt werden, damit man dies pro User definieren könnte.)

Bei jedem Login und/oder Logout (Codeunit 1) könnte dann geprüft werden, ob es in der Tabelle Sessions gibt, welche diese IDLE-Time (Leerlaufzeit) überschritten hat.
Alle Sessions, welche diese Zeit überschritten haben, würden dann gelöscht.
Alternativ könnte man diese Aufgabe auch einem NAS über die Projektwarteschlange in regelmäßigen Abständen prüfen lassen.
(Die Prüfung liegt dann in einer eigens dafür angelegten Codeunit, welche von der Projektwarteschlange aufgerufen würde.)

Timo,

danke für die schnelle Antwort. Leider - wobei das etwas widersinnig klingt - funktioniert dieser Bug nur unter 2009 SP1
und nicht in meinem 5.1. Einen 2009er Client habe ich bisher aber nur auf einem Test-Server selber installiert, und der
stürzt bereits bei dem Versuch ab, die Datenbank zu konvertieren .... Leider konnte mir bisher noch niemand meine
Frage beantworten - auch mein Systemhaus und der Tracer nicht - warum das immer nach 3 Sekunden mit einem
CREATE USER [] FOR LOGIN [] endet. Aber das ist ein anderes Thema ...

Auf jeden Fall - wie von Dir beschrieben - lässt das kleine Prog. mit dem RecRef den 2009er Client sofort über die Wupper
gehen, und die TCP connection, die auch lokal auf dem Server aufgebaut wird, ist danach sofort beendet. Ob das nun
repräsentativ ist, die connections also auch bei einem Absturz auf einem Client PC geschlossen würde, kann ich erst sagen,
wenn ich mir dort einen 2009er Client installiert habe.

Ideen, wie man die Sessions periodisch beenden könnte, hatte ich auch schon, aber ich bin immer noch der Meinung dass
bis vor einigen Wochen alle Connections und damit alle Sessions immer automatisch beendet wurden.

Danke für die Tipps

Pidi

danke für die schnelle Antwort. Leider - wobei das etwas widersinnig klingt - funktioniert dieser Bug nur unter 2009 SP1
und nicht in meinem 5.1

Auf meinem 5SP1 klappt das super. Frag mal deinen NSC nach einem Update auf einen Client, der vernünftig funktioniert!

Methoden zu finden, wie man NAV zum Absturz bringt, sollte jetzt nicht das Problem sein. Die gibt es ja zu Haufen. Einfach mal hier im Forum suchen...

Ideen, wie man die Sessions periodisch beenden könnte, hatte ich auch schon, aber ich bin immer noch der Meinung dass
bis vor einigen Wochen alle Connections und damit alle Sessions immer automatisch beendet wurden.

Hat sich denn irgendwas seitdem geändert? Windows Updates, Einstellungen, Netzwerk, irgendwas...

Ich glaube, ich bin der Sache auf der Spur, denn Absturz ist nicht gleich Absturz ...

Es gibt ja diese Abstürze des Clients, bei denen dann dieser Microsoft Hinweis mit "Senden/Nicht senden" angezeigt wird, in dem
normalerweise auch der Haken gesetzt ist, dass der Client bitte sofort wieder neu gestertet werden soll.

Es gibt jedoch auch Abstürze, wo es plötzlich "Puff" macht, und es apssiert gar nichts weiter. Ich nutze beispielsweise eine DLL
für meine TAPI Lösung, die einen Event-Trigger innerhalb einer Navision SI Codeunit bedient. Stoppt der Server-Dienst aus welchen
Gründen auch immer, scheint diese DLL sich zu verabschieden, woraufhin der Event-Trigger anscheinend so irritiert ist (keine Ahnung
ob da mit Hooks gearbeitet wird), dass der Client in Sekundenbruchteilen vollständig verschwindet. Und genau das sind die Fälle, in
denen die Connections (nachvollziehbar) nicht geschlossen werden. Einen ähnlichen Effekt hatte kürzlich auch ein virtualisierter
Server, der plötzlich einen Blue-Screen bekam. Glücklicherweise passiert so etwas ja nur selten.

Mich wundert schon, dass ich unter dem von MS erwähnten RegKey

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

die genannten Parameter

The parameters involved are KeepAliveInterval, KeepAliveTime, and TcpMaxDataRetransmissions

auf meinen Servern nicht finde. Ich werde aber wohl auch nicht daran herumfummeln, bevor ich nicht ganz sicher bin, welche
Einstellung welche Auswirkungen hat. Und ansonsten gibt da ja noch die von Timo vorgeschlagenen Möglichkeiten!

Danke für alle Kommentare

Pidi