[GELÖST] Client friert ein

[MichaelK]

Hallo,

wir haben das folgende Problem: Bei Aufruf von PAGE.RUNMODAL kann es ab einer höheren Benutzeranzahl (>6), dass alle Clients, die am gleichen Dienst angemeldet sind, für ca. 2 Minuten einfrieren. In dieser Zeit ist es nicht möglich sich an diesem Dienst anzumelden. Danach läuft alles normal weiter als ob nichts gewesen wäre.

Wir haben schon die Zeitsynchronisation überprüft. Wir haben auch den folgenden Wert verändert:

<add key="ClientServicesKeepAliveInterval" value="300" />

der NST und SQL Server laufen auf einer VMWare

In der Ereignisanzeige steht das folgende:

Source: mscorlib
HResult: -2146232828
----------------------------------
Type: Microsoft.Dynamics.Nav.Types.Exceptions.NavSessionTerminatedException
Message: Der Server hat die Sitzung (ID: 220) aufgrund einer Anforderung zum Anhalten der Sitzung angehalten.
StackTrace:
bei Microsoft.Dynamics.Nav.Runtime.SessionAccessLock.ThrowSessionTerminatedException()
bei Microsoft.Dynamics.Nav.Service.ServiceCall.GetClientReturnValue(Action invokeCallback)
bei Microsoft.Dynamics.Nav.Service.NSClientCallback.FormRunModal(NavForm form, NavFormRuntimeParameters parameters)
bei Microsoft.Dynamics.Nav.Runtime.NavForm.RunModal(NavRecord record, Int32 fieldNo)
bei Microsoft.Dynamics.Nav.Runtime.NavForm.RunModal(Boolean isInLookupTrigger, Boolean isLookup, Int32 formId, NavRecord record, Int32 fieldNo)
bei Microsoft.Dynamics.Nav.Runtime.NavForm.RunModal(Boolean isInLookupTrigger, Boolean isLookup, Int32 formId, NavRecord record)
bei Microsoft.Dynamics.Nav.BusinessApplication.Codeunit50000.ShowProductionBOMNo_Scope.OnRun()
bei Filter.InvokeWithFilter(NavMethodScope )
bei Microsoft.Dynamics.Nav.BusinessApplication.Codeunit50000.ShowProductionBOMNo(INavRecordHandle itemVar)
bei Microsoft.Dynamics.Nav.BusinessApplication.Codeunit50000.OnInvoke(Int32 memberId, Object[] args)
bei Microsoft.Dynamics.Nav.BusinessApplication.Page99000789.a60Action1000000004a62_a45_OnAction_Scope.OnRun()
bei Filter.InvokeWithFilter(NavMethodScope )
bei Microsoft.Dynamics.Nav.BusinessApplication.Page99000789.a60Action1000000004a62_a45_OnAction()
Source: Microsoft.Dynamics.Nav.Ncl
HResult: -2146233088

Der Kunde verwendet NAV 2013 R2 CU 27 Build 43896

Hat jemand von Euch eine Idee woran das liegen könnte.

Microsoft kommt da leider nicht weiter.

Gruß

Michael

Zuletzt geändert von MichaelK am 11. Januar 2016 09:23, insgesamt 1-mal geändert.

Hallo Michael, kommt es bei beliebeiger Page oder nur bei einer bestimmten vor? Gemäß Fehlermeldung in der Ereignisanzeige ist wohl eine kundenspezifische Codeunit 50000 + irgend eine Anzeige der Prod. Stückliste in einer Page im Spiel. Vlt. hilft es, in einer Test-DB die Kundenanpassung in der Page testweise zu deaktivieren und dann schauen, ob es daran gelegen hat bzw. diese Kundenanpassung zu analysieren. Vlt. wird irgend eine Anzeige per temporären Record aufegbaut, welche nicht ganz performant gelöst ist.

Hallo Jupiter,

danke für Deine Reaktion. Das Einfrieren passiert überall dort wo PAGE.RUNMODAL verwendet wird.

Gruß

Michael

Verstehe ich die Antwort richtig dass es nicht nur bei dieser Codeunit und Page passiert? Sonst würde ich dort mal prüfen ob überall mit passenden Schlüsseln gefiltert wird und ähnliche Performance-Dinge.

Hallo,

hier der Aufruf aus der Funktion welche in der Ereignisanzeige erwähnt wird.

Code:

  IF itemVersionLoc."Production BOM No." <> '' THEN BEGIN
    prodBOMHeaderLoc.GET(itemVersionLoc."Production BOM No.");
    IF prodBOMVersionLoc.GET(
      prodBOMHeaderLoc."No.", itemVersionLoc."Production BOM Version Code")
    THEN BEGIN
      prodBOMVersionLoc.SETRANGE("Production BOM No.",itemVersionLoc."Production BOM No.");
      PAGE.RUNMODAL(PAGE::"Production BOM Version", prodBOMVersionLoc)
    END ELSE BEGIN
      PAGE.RUNMODAL(PAGE::"Production BOM", prodBOMHeaderLoc);
    END;
  END;

Meiner Meinung nach brauchen da keiner Schlüssel gesetzt werden.

Gruß

Michael

Gibt es in beiden Pages evtl. irgend eine Anpassung? Wenn ja, dann würde ich als erstes diese durch pure NAV-STANDARD Pages ersetzen und schauen, ob das Problem dadurch weg ist (wg. dem ObjectCache den NAV-Dienst nicht vergessen neu zu starten). Wenn das Problem weg ist, dann per Textvergleich die Pages abgleichen, um die Differenzen rauszufinden. Und was mich noch wundert: in der Ereignisanzeige wird die Page 99000789 erwähnt, dies ist die Page "Production BOM Version Lines" die als SubPage in der Page "Production BOM Version" verwendet wird. Vlt. verursacht diese SubPage (Page 99000789) den Fehler, vlt. ist in dieser irgend ein kaputtes FlowField eingeblendet u.s.w, man sollte auf jeden Fall auch diese Page anschauen.

Hallo Jupiter,

dieses Problem tritt auch bei Standardpages auf. Das Problem ist, dass dieses Verhalten nicht einfach zu reproduzieren ist. In den meisten Fällen funktioniert das auch ohne Probleme.

Gruß

Michael

Hallo,

auf welchen wert hast du den den "Metadata Provider Chache Size" des ServiceTiers gesetzt. Falls der unter 150 oder gar 0 ist, dreh den mal auf 1000 hoch.

Ich gehe mal davon aus, das das ganze Problem in einem lokalen Netzwerk mit mindestens 100Mbit/s- Netzwerkgeschwindigkeit stattfindet.

Du solltest weiterhin prüfen, ob in so einem Fall euer SQL- Server ins Schwitzen kommt. Falls ja, ist da etwas programmtechnisches im Argen, oder der SQL- Server läuft auf einem Taschenrechner.

Gruß Fiddi

Hallo Fiddi,

vielen Dank für Dein Statement. Der Metadata Provider Cache Size ist bei 5000. Während des Einfrierens der Clients passiert auf dem SQL-Server gar nichts.

Ja, das Problem tritt in einem lokalen Netzwerk. Wobei der SQL und der NST Server über VMWare virtualisiert sind.

Gruß

Michael

Vlt. kann man die Ursache des Problems mit dem NAV Application Profiler rausfinden. Wobei es schwierig wird, denn das Problem tritt ja sporadisch auf. Man müßte dann die betroffenen Pages mehrmals starten (mit dem aktivierten NAV Application Profiler) und dann hoffen, dass der NAV Application Profiler dann irgednwann den Performancekiller anzeigt. Ansonsten fehlt mir nichts mehr ein.

Hallo,

ich kann mich an ein ähnliches Phänomen mit NAV 2013 unter Citrix und Vmware erinnern.
Dort war es so, wenn ich mich richtig erinnere, dass der RTC von NAV2013 auch für 2 Minuten blockierte, wenn man die Auflösung des Citrix- Fensters durch drücken auf den Maximieren- Button änderte, während der RTC lief. Die Änderung der Bildschirmauflösung durch Auswahl der entsprechenden Optionen im System- Menü des Citrix- Fensters funktionierte hingegen problemlos. Lösung gabs damals keine, außer die Bildcshirmgröße nicht auf diese Weise zu ändern.

Gruß Fiddi

Hallo Fiddi,

vielen Dank für den Tipp. Citrix wird nicht eingesetzt. Wir haben in der Zwischenzeit eine Umgebung ohne VMWare aufgebaut. Dort tritt der Fehler ebenfalls auf. Die obere Meldung aus der Ereignisanzeige ist eine Standardmeldung, wenn der NST-Dienst neugestartet wird und ein Client befindet sich im Runmodal-Modus. Sie ist also nicht sehr aussagekräftig.

Wir vermuten, dass nicht der Client sondern der NST-Dienst bei der Verarbeitung einfriert, denn alle Clients welche mit diesem Dienst verbunden sind zeigen keine Reaktion. Erst nach ca. 2-20 Minuten geht es ohne Probleme weiter.

Gruß

Michael

Schon aktuelles Build probiert?

Gruß Fiddi

Hallo Fiddi,

danke für diesen Tipp, aber wie ich schon ganz oben beschrieben habe:

Der Kunde verwendet NAV 2013 R2 CU 27 Build 43896

müsste der Kunden die aktuellste Buildversion verwenden.

Gruß

Michael

Der Kunde verwendet NAV 2013 R2 CU 27 Build 43896

müsste der Kunden die aktuellste Buildversion verwenden.

Mittlerweile gibt es ja ein neueres, Build 43896 ist auch CU 26, nicht CU 27. Das gibt es erst seit 2 Tagen mit Build 44366.

Hallo,

vielen Dank für Eure Hinweise.

Nach langer Zeit haben wir nun das Problem lokalisieren können. Schuld an dem Einfrieren der Clients und des NST ist die Einstellung "MaxConcurrentCalls". Der Standardwert dort ist 40. Jeder Aufruf von Runmodal ist ein Call, der solange die Page geöffnet ist auch nicht geschlossen wird. Sobald ich die Anzahl von 40 Calls über Runmodal erreicht habe, frieren die Clients und NST ein. Wenn man, z. B. in einer Page, die per Runmodal aufgerufen wurde ebenfalls ein Runmodal-Aufruf hat, dann kann die Anzahl von 40 schnell erreicht werden. Um das Verhalten schnell nachzustellen, reicht es den Wert von "MaxConcurrentCalls" z. B. auf 1 zu setzen.

Gruß

Michael

Wow, krass. Das hätte ich nicht erwartet, dass sich das so auswirkt... Danke für die Info, steht bei uns pro NST auf 150 für ca. 80 Benutzer. Mal schauen ob das ausreicht, wenn wir live gehen.

Hallo Carsten,

ja, wir haben den Wert auf MaxValue gesetzt bis Microsoft hier eine bessere Fehlerbehandlung hat. Denn die Auswirkungen sind extrem. Niemand kann mehr arbeiten, der am betroffenen NST angemeldet ist.

Habt Ihr den Wert bei MaxConcurrentCalls auf 150 geändert oder meinst Du den Wert MaxConcurrentConnections?

Übrigens, die Fehlermeldung von meinem ersten Post hat gar nichts mit dem Problem zu tun. Sie entsteht, wenn man ein Client, welcher im Runmodal-Modus eingefroren ist über den Task-Manager abschießt.

Gruß

Michael

Hallo Michael,

Habt Ihr den Wert bei MaxConcurrentCalls auf 150 geändert oder meinst Du den Wert MaxConcurrentConnections?

Nein, ich meine schon MaxConcurrentCalls. Connections und Calls sind nun identisch. Es können nun also bei jedem der 80 Benutzer ca. 2 modale Pages offen sein, sollte passen.

Hallo Michael,

wir hatten genau das gleiche Problem. Vielen Dank für das Posten dieses Zusammenhangs. Das war ein echter Bringer.
Wie genau bist Du auf den Zusammenhang zwischen Calls und Page.Runmodal gekommen ?

Gruß und nochmal tausend Dank,
Dennis

Hallo,

vielen Dank für Eure Hinweise.

Nach langer Zeit haben wir nun das Problem lokalisieren können. Schuld an dem Einfrieren der Clients und des NST ist die Einstellung "MaxConcurrentCalls". Der Standardwert dort ist 40. Jeder Aufruf von Runmodal ist ein Call, der solange die Page geöffnet ist auch nicht geschlossen wird. Sobald ich die Anzahl von 40 Calls über Runmodal erreicht habe, frieren die Clients und NST ein. Wenn man, z. B. in einer Page, die per Runmodal aufgerufen wurde ebenfalls ein Runmodal-Aufruf hat, dann kann die Anzahl von 40 schnell erreicht werden. Um das Verhalten schnell nachzustellen, reicht es den Wert von "MaxConcurrentCalls" z. B. auf 1 zu setzen.

Gruß

Michael

Hallo Dennis,

für die Analyse ist viel Zeit draufgegangen. Wir haben dafür einen Job gebastelt, der Pages mehrfach aufruft. Damit konnten wir das Verhalten nachstellen. Microsoft hat uns dann den schuldigen Parameter für das Verhalten geliefert.

Gruß

Michael