Server Cache

[Jan]

Moin,

nur um Euch mal daran teilhaben zu lassen. Und wenn Ihr ähnliche Probleme habt als Idee was da los sein kann.

Das Szenario: Bei meinem Kunden laufen ca. 45 Server im HyperV. Auf einem davon liegen all die Programme, die ich für den schreibe. Mit allen Xbase++-Runtimes im gleichen Verzeichnis Auf einem anderen werden verschiedene dieser Programme über eine Laufwerksfreigabe gestartet, die laufen da 7/24. Und ja, nur um das klarzustellen: Die ganzen Programme werden grundsätzlich auf dem entfernten Server gestartet. Auch auf den Clients der Mitarbeiter werden die nicht lokal vorgehalten.

Gestern habe ich dann auf dem Server mit den Programmen die Xbase++-Runtimes aktualisiert. Die alten waren noch vom vergangenen Jahr. Da dazu alle User raus und alle Programme beendet sein müssen mache ich das nicht ganz so häufig. Meist dann wenn es etwas für den Kunden relevantes neues gibt, oder anderweitig Wartungsarbeiten anliegen.

Nach dem Update konnte ich ein Programm nicht mehr starten. Laufzeitfehler wegen Versionskonflikt. Dieses ist das einzige Programm, das die PGDBE nutzt (nur zum Auslesen einer PostreSQL der Telefonanlage). Und wie Alaska in dem Newsletter vom März diesen Jahres erklärte haben die da ein Build binding eingebaut. Das löst hier den Fehler aus.

Fehlersuche: Ja, ich habe alle Runtimes kopiert (außer zwei ADS-dll, weil Alaska da uralte Versionen mitliefert, ich aber die aktuellen benötige). Ja, alle Programme hatte ich vor dem Update beendet und hinterher neu gestartet. Rufe ich xppload in dem Verzeichnis mit den Programmen auf passt auch alles. Rufe ich xppload dagegen auf dem Server auf, wo die 7/24-Programme laufen, sind ca. 2/3 der Runtimes mit dem alten Versionsstand. ?!?!? Was ist da los? Also Gegentests von anderen Clients aus, die kein Xbase++ installiert haben. Gleiches Ergebnis.

Das erklärt die Fehlermeldung beim Start dieses Programmes. Aber nicht warum da diese alten Runtimes aufgeführt werden. Auch der Admin hatte keine Idee.

Die Lösung: Neustart des Servers mit den 7/24-Programmen. Danach lief alles wieder korrekt. Als hätte der die Runtimes im Cache vorgehalten. Aber warum? Und warum nur manche?

Manche Dinge muß ich nicht verstehen. Zum Glück hat das den Laden bei meinem Kunden nicht groß gestört. Und mich "nur" 3/4 Stunde Zeit gekostet und einige Nerven. Aber ärgerlich ist das trotzdem.

Jan

[Marcus Herz]

Das Problem mit den gecachten Runtime DLLs gibts auch bei Terminalservern.
Ich geh dann immer über
- Computerverwaltung (man kann sich auch an einem entfernten Computer anmelden)
- System
- Freigegeben Ordner
- geöffnete Dateien
hier finden sich meist die geladene DLLs, welche man dann schliessen kann. Warum die dort noch offen sind ???
Apropos: Jan du schreibst, die Clients starten die Programme über den Server.
EIn Kunde von mir bekam letztes Jahr neue Hardware und Netzwerk. Danach liefen die Programme instabil, ständig ging die Verbindung zum ADS verloren. Jetzt starte ich die Lokal (eine lokale Kopie der kompletten Runtime) und es ist wieder absolut stbail. Konnte mir auch keiner ( der externen Netzwerktechniker) erklären.

[brandelh]

Hallo,

Als die Leitungen noch viel dünner waren, hatten wir eine Routine welche beim Programmstart (über CMD Datei)
die Versionsstande lokale EXE, lokale Runtime (die wird seltener geändert) abgeprüft und notfalls nachgeladen.

Je nach Zahl der Anwender nimmt die Netzlast extrem zu wenn alle vom Server laden müssen.

Ich hatte damals den Datenbestand aber in DBF zentral, nachdem die Leitungen stabiler waren,
der einmalige Mergeprozess war mühsam genug.

Aber alle meine Programme prüfen eine zentrale Netzdatei, wenn die da ist wird es gleich wieder beendet.
Beim laufenden Betrieb prüfte eine Routine ab ob diese Datei auftaucht und spätestens nach 15 Minuten war keiner mehr online.

Sowas hab ich meist um 12 Uhr gemacht, da waren alle in der Mittagspause

Lange ist es her, unter Citrix lief alles über die Server. Anfangs stabil, später ein Albtraum, seit 2021 sind alle außer Dienst.