Welche Prototokollierung anstellen, um Socket error auf die Schliche zu kommen?
Hallo Beisammen,
mein Anwendungsprogramm verweigert sporadisch, aber immer wieder die Zusammenarbeit mit dem Server mit einem nciht weiter beschriebenen Socket error. Um das Problem identifizieren zu können würde ich gerne wissen, ob und wie ich alle Socket errors mit etwas mehr Detailinformation protokollieren lassen kann.
Oder hat jemand unter Euch eine bessere Idee zur Fehlereingrenzung?
Im einzelen:
Hardware
HP ProLiant ML350p Gen8 mit
- Intel Xeon E5-2680 - 2.7 GHz - 8 Kerne - 16 Threads
- 2 DDR3 Speichermodul 16GB - DDR3 1600MHz (PC3-12800R, 2Rx4)
- 460W Netzteil,
- 2 HDD 600GB - SAS-3
- 2 SSD 800 GB
- 2 HDD 1 TB
Server-Software
MS Server 2019 mit bislang einer HyperV-Maschine. In einer HyperV-Instanz laufen folgende Server:
- MS SQL Server
- ELO DMS, wobei bei Ausführung der ELO-Installationsroutine auch installiert wurden ein
- Tomcat-Server
- ELASTIC Server.
Fehlerbeschreibung:
Das ELO- Dokumentensystem läuft bei mir 14/h am Tag, und meistens wie es soll.
Es sei denn es gibt einen Socket error.
Der lässt sich zumeist mit "Neu verbinden" überwinden - manchmal auch nicht. Dann muss man ELO beenden und neu starten. Das funktioniert dann meistens - manchmal auch nicht; dann verweigert der ELO-Client den Start mit der Behauptung, er könne zum Server keine Verbindung herstellen - obwohl ich per RDP auf besagten Server komme und den dort vorsorglich auch installierten ELO-Client starten kann.
Dann muss man den Client-Rechner neu starten. Das funktioniert dann meistens - manchmal auch nicht. Dann verweigert der ELO-Client den Start mit der Behauptung, er könne zum Server keine Verbindung herstellen - obwohl ich per RDP auf besagten Server ... etc wie oben.
Der Neustart des ELO-Server hilft dann nicht.
Doch wenn man nach Stunden nocheinmal den ELO-Client vom Clientrechner aus startet, dann geht es plötzlich wieder.
Eine Systematik, die bei der Ursachenforschung helfen könnte, ist für mich nicht zu erkennen.
Und das blödeste ist: die Socket error Meldung selbst erscheint ohne jede weitere Erklärung:
Ich will jetzt mal versuchen, dem Fehler auf den Grund zu gehen, indem ich ein Protokoll erstellen lassen will, aus dem ich weitere Rückschlüsse auf die Fehlerursache ziehen kann. Meine Frage an Euch: wo (auf dem Server oder/und dem Client) stelle ich welche Prototokollierung wie an, um dem Socket error auf die Schliche zu kommen?
Besten Dank für freundliche Tips im voraus!
J
mein Anwendungsprogramm verweigert sporadisch, aber immer wieder die Zusammenarbeit mit dem Server mit einem nciht weiter beschriebenen Socket error. Um das Problem identifizieren zu können würde ich gerne wissen, ob und wie ich alle Socket errors mit etwas mehr Detailinformation protokollieren lassen kann.
Oder hat jemand unter Euch eine bessere Idee zur Fehlereingrenzung?
Im einzelen:
Hardware
HP ProLiant ML350p Gen8 mit
- Intel Xeon E5-2680 - 2.7 GHz - 8 Kerne - 16 Threads
- 2 DDR3 Speichermodul 16GB - DDR3 1600MHz (PC3-12800R, 2Rx4)
- 460W Netzteil,
- 2 HDD 600GB - SAS-3
- 2 SSD 800 GB
- 2 HDD 1 TB
Server-Software
MS Server 2019 mit bislang einer HyperV-Maschine. In einer HyperV-Instanz laufen folgende Server:
- MS SQL Server
- ELO DMS, wobei bei Ausführung der ELO-Installationsroutine auch installiert wurden ein
- Tomcat-Server
- ELASTIC Server.
Fehlerbeschreibung:
Das ELO- Dokumentensystem läuft bei mir 14/h am Tag, und meistens wie es soll.
Es sei denn es gibt einen Socket error.
Der lässt sich zumeist mit "Neu verbinden" überwinden - manchmal auch nicht. Dann muss man ELO beenden und neu starten. Das funktioniert dann meistens - manchmal auch nicht; dann verweigert der ELO-Client den Start mit der Behauptung, er könne zum Server keine Verbindung herstellen - obwohl ich per RDP auf besagten Server komme und den dort vorsorglich auch installierten ELO-Client starten kann.
Dann muss man den Client-Rechner neu starten. Das funktioniert dann meistens - manchmal auch nicht. Dann verweigert der ELO-Client den Start mit der Behauptung, er könne zum Server keine Verbindung herstellen - obwohl ich per RDP auf besagten Server ... etc wie oben.
Der Neustart des ELO-Server hilft dann nicht.
Doch wenn man nach Stunden nocheinmal den ELO-Client vom Clientrechner aus startet, dann geht es plötzlich wieder.
Eine Systematik, die bei der Ursachenforschung helfen könnte, ist für mich nicht zu erkennen.
Und das blödeste ist: die Socket error Meldung selbst erscheint ohne jede weitere Erklärung:
Ich will jetzt mal versuchen, dem Fehler auf den Grund zu gehen, indem ich ein Protokoll erstellen lassen will, aus dem ich weitere Rückschlüsse auf die Fehlerursache ziehen kann. Meine Frage an Euch: wo (auf dem Server oder/und dem Client) stelle ich welche Prototokollierung wie an, um dem Socket error auf die Schliche zu kommen?
Besten Dank für freundliche Tips im voraus!
J
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3477490088
Url: https://administrator.de/forum/welche-prototokollierung-anstellen-um-socket-error-auf-die-schliche-zu-kommen-3477490088.html
Ausgedruckt am: 27.12.2024 um 04:12 Uhr
7 Kommentare
Neuester Kommentar
Moin,
ich weiss nicht ob du hier was selbst programmiert hast - falls ja würde ich einfach mal vermuten du hast ne Verbindung aufgebaut aber schließt die nicht wieder. Wenn du dann versuchst ne zweite Verbindung parallel aufzumachen kann sowas (je nach Service) passieren... Oder du hast nen Serverdienst programmiert und versuchst z.B. deinen Dienst als Thread oder in ner Schleife mehrfach zu starten. Finden die meisten Programme auch nicht sonderlich lustig ;)
ich weiss nicht ob du hier was selbst programmiert hast - falls ja würde ich einfach mal vermuten du hast ne Verbindung aufgebaut aber schließt die nicht wieder. Wenn du dann versuchst ne zweite Verbindung parallel aufzumachen kann sowas (je nach Service) passieren... Oder du hast nen Serverdienst programmiert und versuchst z.B. deinen Dienst als Thread oder in ner Schleife mehrfach zu starten. Finden die meisten Programme auch nicht sonderlich lustig ;)
Hi,
musst du oder kannst du machen lassen? ELO ist ja nicht gerade bilig. Hast du keinen Support Vertrag?
Meine Test bitfarm hattte sich mal verschluckt. Über GUI ging nichts. Da lag es aber an einer LOCK Datei, die alle weiteren Importe unter dem User verhindert haben. Ohne weglöschen wäre es auch nach 3 Jahren und 1.000 Reboote nicht gegangen.
Wenn der ELO Reboot nicht hilft, wird ggf. was ähnliches locken.
Ist das ELO oder greifst du nur auf deren Interface zu? Log Level kann man ggf. auch bei ELO Server einstellen. Musst mal in die Doku schauen.
musst du oder kannst du machen lassen? ELO ist ja nicht gerade bilig. Hast du keinen Support Vertrag?
Meine Test bitfarm hattte sich mal verschluckt. Über GUI ging nichts. Da lag es aber an einer LOCK Datei, die alle weiteren Importe unter dem User verhindert haben. Ohne weglöschen wäre es auch nach 3 Jahren und 1.000 Reboote nicht gegangen.
Wenn der ELO Reboot nicht hilft, wird ggf. was ähnliches locken.
Ist das ELO oder greifst du nur auf deren Interface zu? Log Level kann man ggf. auch bei ELO Server einstellen. Musst mal in die Doku schauen.
Zitat von @doubleyou:
Nabend Maretz und Danke für die Idee - ne, programmiert habe ich da nichts. Da läuft nur ELO vor sich hin. Aber bedeutet Deine Frage nicht, dass die Ursache in der Anwendung ELO zu suchen ist? D.h. dann auch, dasss ich den WinServer (hard- wie software) und das Netzwerk (Hardware- und softwareseitig) als potentielle Ursache ausschließen kann?
Nabend Maretz und Danke für die Idee - ne, programmiert habe ich da nichts. Da läuft nur ELO vor sich hin. Aber bedeutet Deine Frage nicht, dass die Ursache in der Anwendung ELO zu suchen ist? D.h. dann auch, dasss ich den WinServer (hard- wie software) und das Netzwerk (Hardware- und softwareseitig) als potentielle Ursache ausschließen kann?
Nicht zwingend - es ist ja nen unterschied ob du da was programmierst oder ob das von einer fremdfirma kommt. Z.B. wenn du bei Windows nen lustigen Apache-Webserver hast aber dein Elo auch nen Webserver da auf port 80 aufmachen will wäre das ja auch nen Konflikt - ohne das Elo da was für kann... Aber wenns von da kommt würde ich auch den Hersteller anrufen, die sollten normal Logging-Funktionen haben die eben den Fehler anzeigen und sagen wo man suchen kann. Bei dem was ich programmiere gebe ich ja auch nicht die zig Seiten Java-Fehler an den Anwender (der wäre nur verwirrt). Der sieht ne kleine Fehlermeldung und die Log-File sagt halt wo es geknallt hat und warum... Z.B. würdest du bei Java als Anwender ja mit "Null Pointer" nich viel anfangen können - zumal es dir auch nicht hilft, du kannst ja nix dagegen tun wenn der Entwickler zu blöd war... Dem ENTWICKLER sollte es aber was sagen - und wenn dann noch in der Logfile steht "class xyz, line abc" dann ist so ein Fehler in sekunden gefunden und behoben...oder in wochen... :D
Es gibt auch Fehler die werden nach einen gewissen Standard angezeigt. Nummer + Fehler halt. Webserver und ähnliches. Da können auch tausende von Leuten helfen.
Generell kann man aber munter Fehlerhandling programmieren. Text wird angzeigt und noch ein Schlagwort: Socket Error.
Da kann auch "Meine liebe Oma" stehen. Was ein Socket ist, wissen viele. Es kann am Socket liegen, oder man war faul und hat die Fehler irgendwann in diese Meldung münden lassen.
Wenn es im bestenfall um den Socket geht, ist es trotzdem nicht ganz leicht. Entweder eine andere Anwendung blockiert den Port. Das der Dienst nicht hoch kommt. Oder es wird intern etwas gelocked, wenn der Socket einmal steht. Bleibt der lock, kann es nicht noch einmal gestartet werden.
Kenne ELO nicht. Oft gibt es mehrer Dienste! Sind alle ELO dienste oben? Alles was automatisch gestartet wird?
Sie können es auch in die SQL gepackt haben. Oder ein SQL Lock verhindert das Dienste hoch kommen. Oder oder. Es fallen da einen mehrere Gründe ein.
Netzwerk Erreichbarkeit sagt leider nicht viel aus. Um zu verindern dass Dinge mehrfach gestartet werden gibt es Prüfungen. Ein simples "Socket error" ist nur das Ende eines Rattenschwanzes ,..
PS: Wenn es eine Firma noch gibt, ist es einfacher da etwas Geld in die Hand zu nehmen und Support zu holen.
Selbst Softwareentwickler können bei sowas von extern nur raten. Wenn du einen guten Programmierer an der Hand hat, der an größeren Projekten mitwirkte, kann dir so eine Person evtl. hilfreich sein. Weiß ggf. eher worauf zu achten ist. Versucht die Zusammenhänge zu erarbeiten.
ELO ist ein DMS. Wenn es doch indirekt auf die DB zurück zuführen ist, hast du ggf. andere Probleme. Wegen Archivierungspflicht etc. wäre es ggf. da auch keine schlechte Idee einen Pro drauf schauen zu lassen.
Generell kann man aber munter Fehlerhandling programmieren. Text wird angzeigt und noch ein Schlagwort: Socket Error.
Da kann auch "Meine liebe Oma" stehen. Was ein Socket ist, wissen viele. Es kann am Socket liegen, oder man war faul und hat die Fehler irgendwann in diese Meldung münden lassen.
Wenn es im bestenfall um den Socket geht, ist es trotzdem nicht ganz leicht. Entweder eine andere Anwendung blockiert den Port. Das der Dienst nicht hoch kommt. Oder es wird intern etwas gelocked, wenn der Socket einmal steht. Bleibt der lock, kann es nicht noch einmal gestartet werden.
Kenne ELO nicht. Oft gibt es mehrer Dienste! Sind alle ELO dienste oben? Alles was automatisch gestartet wird?
Sie können es auch in die SQL gepackt haben. Oder ein SQL Lock verhindert das Dienste hoch kommen. Oder oder. Es fallen da einen mehrere Gründe ein.
Netzwerk Erreichbarkeit sagt leider nicht viel aus. Um zu verindern dass Dinge mehrfach gestartet werden gibt es Prüfungen. Ein simples "Socket error" ist nur das Ende eines Rattenschwanzes ,..
PS: Wenn es eine Firma noch gibt, ist es einfacher da etwas Geld in die Hand zu nehmen und Support zu holen.
Selbst Softwareentwickler können bei sowas von extern nur raten. Wenn du einen guten Programmierer an der Hand hat, der an größeren Projekten mitwirkte, kann dir so eine Person evtl. hilfreich sein. Weiß ggf. eher worauf zu achten ist. Versucht die Zusammenhänge zu erarbeiten.
ELO ist ein DMS. Wenn es doch indirekt auf die DB zurück zuführen ist, hast du ggf. andere Probleme. Wegen Archivierungspflicht etc. wäre es ggf. da auch keine schlechte Idee einen Pro drauf schauen zu lassen.
Als erstes solltest du bei Support Nachfragen, was die Programmierer der Fehlermeldung unter "Socket Error" zusammengefasst haben. Sowas versteht jeder Programmierer anders.