SocketError bei Aufruf eines SOAP-Servers

[Maliko]

Guten morgen,

ich hoffe ihr könnt mir weiter helfen, weil ich langsam echt mit meinem Latein am Ende bin. Und zwar habe ich seit ca. einer Woche das Problem das einer unserer SOAP-Clients Verbindungsprobleme zum Server hat. Allerdings nicht durchgängig. Der Client führt jeden morgen um 05:30 Uhr automatisch eine Aufgabe aus und wird von der Windows Aufgabenplanung gestartet. Das Problem ist wie folgt.

Der Client wird gestartet und ca. die erste halbe Stunde bekommt er bei jedem Request (es handelt sich dabei um die Anmeldung beim Server, also eine Loginfunktion, was aber ein normaler Endpunkt ist) die folgende Fehlermeldung:

java.net.SocketException: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat

Diese Fehlermeldung kommt wirklich jeden morgen ungefähr die erste halbe Stunde und dann funktioniert es plötzlich. Lediglich am Wochenende funktionierte es gar nicht. Da bekam ich insgesamt 3 1/2 Stunden diese Fehlermeldung bis das System abbrach. Um evntl. Wartungsarbeiten beim Serverbetreiber auszuschließen, habe ich gestern die Ausführung um eine Stunde nach vorne verlegt. Doch wieder das selbe Problem. Wieder etwas über 20 Minuten diese Fehlermeldung bis es dann plötzlich funktioniert.

Hier einmal eine genaue Auflistung der Zeiträume zum besseren Verständnis:

17.01.2023: 06:31 – 06:53 Uhr
16:01.2023: 05:31 – 06:00 Uhr
15.01.2023: 05:31 – 09:04 Uhr (danach hat das System abgebrochen, es wurde also gar nichts gemacht)
14.01.2023: 05:31 – 09:00 Uhr (danach hat das System abgebrochen, es wurde also gar nichts gemacht)
13.01.2023: 05:31 – 06:04 Uhr
12.01.2023: 05:31 – 06:16 Uhr
11.01.2023: 05:31 – 06:00 Uhr

Jeweils unmittelbar nach der letzten Fehlermeldung ging dann der erste erfolgreiche Request raus. Das einzige was mir zusätzlich noch aufgefallen ist, am 12.01., 13.01. und heute bekam ich als letzten Fehler bevor es funktionierte einen SSL Fehler und zwar folgenden:

javax.net.ssl.SSLException: Received fatal alert: bad_record_mac

Der Stacktree ist dabei zu 100% Identisch zu dem anderen Fehler (hab beide Stacktrees mal in ein Textvergleichstool geworfen und das spuckte mir eine 100%ige Übereinstimmung aus). Merkwürdig ist allerdings dass diese Fehlermeldung in den letzten 7 Tagen genau 3 mal geworfen wurde und jedes mal funktionierte es im Anschluss dann.

Hat vielleicht irgendjemand von euch eine Ahnung was es sein könnte? Einen Programmierfehler schließe ich eigentlich aus, weil das Programm vorher schon mehrere Wochen problemlos funktionierte ohne das Änderungen am Source-Code vorgenommen wurden.

Vielen Dank schon einmal im Voraus.

Viele Grüße
Maliko

PS: Ich kann auch gerne die entsprechende Stelle im Source-Code posten, das wird jedoch denke ich nicht viel nutzen, weil es einfach nur ein Soap-Request ist, sprich ich rufe einen Soap-Endpunkt auf.

 

[Maliko]

Vieleicht hilft es noch zu wissen, welche Java-Version wir nutzen. Hier einmal das ergebnis von java -version:

java version "17.0.5" 2022-10-18 LTS
Java(TM) SE Runtime Environment (build 17.0.5+9-LTS-191)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.5+9-LTS-191, mixed mode, sharing)

 

[KonradN]

Es könnte auch interessant sein, welche Library ihr für SOAP Requests verwendet. Dürfte ja vermutlich eine jax-ws Implementation sein.
Und der volle Stacktrace kann auch nicht schaden.

 

[Maliko]

Jap es ist ne jax-ws Implementierung. Hier auch der Stacktrace:

[com.sun.xml.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:182), com.sun.xml.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:216), com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:207), com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:120), com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:80), com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1105), com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1019), com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:988), com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:846), com.sun.xml.ws.client.Stub.process(Stub.java:432), com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:161), com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77), com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:61), com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:131), jdk.proxy2/jdk.proxy2.$Proxy36.login(Unknown Source), asekvwebservice.ASEKVServiceImpl.loginToEgeko(ASEKVServiceImpl.java:718), asekvwebservice.ASEKVServiceImpl.sendMails(ASEKVServiceImpl.java:532), jdk.internal.reflect.GeneratedMethodAccessor20.invoke(Unknown Source), java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43), java.base/java.lang.reflect.Method.invoke(Method.java:568), com.sun.xml.ws.util.Trampoline.invoke(MethodUtil.java:52), jdk.internal.reflect.GeneratedMethodAccessor15.invoke(Unknown Source), java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43), java.base/java.lang.reflect.Method.invoke(Method.java:568), com.sun.xml.ws.util.MethodUtil.invoke(MethodUtil.java:77), com.sun.xml.ws.api.server.MethodUtil.invoke(MethodUtil.java:34), com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:220), com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:119), com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:58), com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1105), com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1019), com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:988), com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:846), com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:400), com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:838), com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:392), com.sun.xml.ws.transport.http.server.WSHttpHandler.handleExchange(WSHttpHandler.java:83), com.sun.xml.ws.transport.http.server.WSHttpHandler.access$000(WSHttpHandler.java:32), com.sun.xml.ws.transport.http.server.WSHttpHandler$HttpHandlerRunnable.run(WSHttpHandler.java:107), java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136), java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635), java.base/java.lang.Thread.run(Thread.java:833)]

Zeile 718 in ASEKVServiceImpl.java ist folgende:

this.port.login(user.getUsername(), user.getPassword(), user.getEgekoSoftwarekey());

 

[KonradN]

Was ich mich gerade frage: Kann das ggf. ein Timeout Problem sein? Setzt ihr irgendwelche Timeouts? Wie viel Zeit vergeht von Request absenden bis zur Fehlermeldung? Nicht dass der Server noch mit Backups beschäftigt ist und am Wochenende Reorganisationen laufen, die Antworten so verlangsamen, dass es zu Timeouts kommt?

Was mich etwas wundert ist diese SSL Fehlermeldung. Das deutet etwas darauf hin, dass der Server etwas nicht unterstützt. Kann es evtl. doch ein Problem am Zielserver sein? Und der hat ein Problem und das ist dann irgendwann behoben? Und am Wochenende ist niemand da, der das Problem behebt? Ich frage ja nur ... So unwahrscheinlich das auch sein mag aber es sieht alles irgendwie dubios aus.

Evtl. mal paar andere Dinge testen - versuch z.B. in der problematischen Zeit die WSDL des Services abzurufen. Das kannst Du ja mittels curl oder so machen. Wenn Du es mit Java machst - schau mal, ob Du mit System.setProperty("javax.net.debug", "all"); mehr Informationen bezüglich der Verbindung bekommst.

Das wäre so im Augenblick paar Ideen, die mir kommen, aber das sind schon teilweise weit hergeholte Ideen ... Zeigt einfach, dass ich da derzeit auch keine wirklich gute Idee habe.

 

[Maliko]

Auf die Idee sind wir tatsächlich auch schon gekommen und unsere Admins sind gerade dabei ein Powershell-Script zu schreiben, welches nen Trace auf die WSDL machen soll. Das lassen wir dann zeitgleich zum Client laufen. Mal schauen was dabei raus kommt.

Und was die Timeouts angeht, wir selbst setzten keine Timeouts. Es handelt sich also um den Standartmäßigen Timeout (der bei ca 60 Sekunden, liegt, weil wir ungefähr alle 60 Sekunden eine Fehlermeldung bekommen). Diese SSL-Fehlermeldung wundert mich auch, alleine schon weil sie nur insgesamt 3x innerhalb von 7 Tagen vorgekommen ist (bei insgesamt um die 220 Fehlermeldungen). Das einzige was es evntl. sein könnte ist, dass der Client noch auf SSL1.2 arbeitet und noch nicht auf 1.3 umgestellt wurde. Das wäre noch ne möglichkeit die ich beim Anbieter mal anfragen könnte ob 1.3 bei denen überhaupt funktioniert.

 

[KonradN]

Aber die SSL Konfiguration ändert sich ja nicht ständig. Daher wäre das immer ein Problem oder nie….

Oder du erwischt den Server bei irgendetwas (Neustart?) und daher geht es danach dann?

Aber halt nur, weil mir nichts besseres einfällt ….

 

[LimDul]

Solche Probleme sind extrem häßlich. Uns hat sowas mal einen Monat und eine Menge Entwicklerkapazität gekostet. Bei uns war es am Ende eine falsch konfigurierte Statefull Firewall, die Verbindungen gedroppt hat.

Daher zumindest mal die Anregung auf den Netzwerk-Layer zu schauen? Irgendwelche Interessanten Komponenten dazwischen? Besteht eine Chance den Zugriff mal parallel aus einem komplett anderen Netzwerk laufen zu lassen? Also zu schauen, ob das Problem - sofern es wirklich Netzwerk ist - bei ein- oder ausgehenden Netzwerk ist?

Wir haben am Ende mit TCPDump die Pakete geloggt und konnten dadurch rausfinden an welcher Stelle es zum Timeout kam. Wir hatten aber alle Komponenten unter Kontrolle, das hört sich hier nicht so an, als wäre der Zielserver unter Kontrolle. Und ihr habt ssl, was es auch schwieriger macht.

Von daher weiß ich nicht, ob meine Vorschläge wirklich helfen, aber was besseres sehe ich von außen gerade nicht.

 

[Maliko]

Uff gute Frage. Da habe ich überhaupt keine Ahnung von, da das zum Aufgabenbereich unserer Admins gehört. In alles was Netzwerk und/oder Firewall oder ähnliches betrifft hab ich überhaupt keinen Einblick. Ich werd deinen Beitrag morgen aber mal an unsere Admins weiterleiten.