Server Cache
Verfasst: Mi, 19. Jul 2023 9:04
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
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