Verbindungsprobleme bei STS

[MiSFiT]

Ich versuche es mal


Stellwerk: egal welches Problem trifft bei jedem auf
Real-Uhrzeit: egal wann passiert immer
Spiel-Uhrzeit: siehe oben
Spielinstanz:egal welcher
Modus (Online, Sandbox): Online sowie Sandbox sowie wenn ich überhaupt kein Stw offen habe
verwendete Anti-Virensoftware, Firewall und/oder Security-Suite: Bitdefender
Verbindung zum Internet (WLAN/LAN/Mobiles Internet [z.B. GSM, UMTS, …]) : Über LAN
Fehlerbeschreibung (logisch) :nach unbestimmter Zeit Verbindungsabbrüche


hab ich was vergessen ?

[oberrheiner]

Also wenn das Problem immer auftritt, dann bleibt mir nichts anderes übrig als einen Fehler auf Seiten des STS mit 99% Wahrscheinlichkeit auszuschließen.
Was ich mich aber frage, wie sah es denn vor dem Kommunikator aus. Wie sahen dort die Verbindungsabbrüche aus, wenn kein Spiel lief?

[Interpret]

Vielleicht hängt das Problem mit meinem heutigen Problem zusammen

Code: Alles auswählen

Oct 05, 2016 6:00:33 PM js.java.schaltungen.chatcomng.GlobalLatency commandEvents
WARNING: IRC Latenz: 502 ms
Oct 05, 2016 6:02:20 PM js.java.schaltungen.chatcomng.GlobalLatency commandEvents
WARNING: IRC Latenz: 1,573 ms
Oct 05, 2016 6:02:21 PM js.java.soap.ServiceAccessor runNow
SEVERE: null
com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 503: Service Unavailable
	at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.checkStatusCode(HttpTransportPipe.java:310)
	at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:259)
	at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:217)
	at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:130)
	at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:95)
	at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:1121)
	at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:1035)
	at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:1004)
	at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:862)
	at com.sun.xml.internal.ws.client.Stub.process(Stub.java:448)
	at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:178)
	at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
	at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77)
	at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:147)
	at com.sun.proxy.$Proxy34.storeLatency(Unknown Source)
	at js.java.schaltungen.webservice.WebServiceConnector.lambda$storeLatency$3(WebServiceConnector.java:58)
	at js.java.soap.ServiceAccessor.runNow(ServiceAccessor.java:50)
	at js.java.soap.ServiceAccessor.lambda$run$0(ServiceAccessor.java:41)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

Fehler ist mit
Build: 5457
Java: 1.8.0_102; Java HotSpot(TM) 64-Bit Server VM
Runtime: Java(TM) SE Runtime Environment; 1.8.0_102-b14
Arch: 64; running on amd64; 8 cores
OS: Linux; version 4.4.0-39-generic
heute wiederholt aufgetreten.
Im Chat kommt dann die Meldung "SEVERE: null" und dann ist der Sim tot, der Chat läuft aber weiter.

[MiSFiT]

Also wenn das Problem immer auftritt, dann bleibt mir nichts anderes übrig als einen Fehler auf Seiten des STS mit 99% Wahrscheinlichkeit auszuschließen.
Was ich mich aber frage, wie sah es denn vor dem Kommunikator aus. Wie sahen dort die Verbindungsabbrüche aus, wenn kein Spiel lief?

Ich weiß jetzt leider nicht genau was bzw. wie du das meinst. Vor diesen externen Programm konnte ich auch gerne mal 4 Stunden + durchspielen ohne Probleme.

[FFM]

So dann will ich auch mal meinen Senf dazu geben:

Ich bin heute schon das 6. mal rausgeflogen, grund?!?? keine ahnung....

Ist auch erst neu und I-net verbindung ist auch einwandfrei.....auch schon alles Aktualisiert etc.

[abrixas]

Heute früh gibt es teilweise große Probleme mit der Erreichbarkeit des Stellwerksim, wenn man einen Anschluss bei Telecolumbus hat.
Aus anderen Netzen sind unsere Server problemlos zu erreichen.

Das zeigt sehr schön das nicht immer die Server schuld sein müssen. Solche Probleme ist oftmals für den normalen Benutzer nicht einfach zu erkennen, weil zwar noch alles funktioniert, aber teilweise sehr langsam.

[Cunwad]

Nach ca. 1 Woche mal wieder in nen Stw gejoint. Von Anfang an hatte ich große Latenzen beim Stellen von Übergabe-FS. Aufrufen von Webseiten ging problemlos, binnen 1s war alles da, sowohl über http als auch über https. Im STS kassierte ich nach 40 min wieder nen Timeout, als gerade die ersten Züge das Stw in der gesamten Länge passiert haben. Während die Übergaben blinken andere Webseiten aufrufen, ist kein Problem.

Letzte Woche flog ich nach mehreren Stunden Spiel kurz nach 20 Uhr. Der Verbindungsaufbau läuft nun deutlich schneller als vor ein paar Wochen, aber danach steigen die Latenzen wieder erheblich an.

Edit:
Ach ja, bin über Vodafone drin.

[oberrheiner]

Vodafone? Also UMTS?
Und wann war denn das ganze was du oben beschreibst? So ein paar mehr Infos wären schön.
Hattest du Nachbarn?
In welchem Stellwerk warst du?
...

[driverman]

Nicht unbedingt, Vodafone hat auch Festnetzanschlüsse (Habe ich nämlich auch). Läuft aber erstmal über die gleichen Leitungen wie Telekom und Co. auch und wird dann an Vodafone übergeben. Dieser Punkt ändert sich auch. So hatte ich bei Popups mit regionalem Bezug schon ziemlich viele Orte im nördlichen Baden-Württemberg dabei obwohl ich aus der Region Karlsruhe stamme.

Verbindungsprobleme mit STS habe ich eigentlich nur dann, wenn ich auf die "sinnvolle" Idee komme neben STS her ein Video zu YT hochzuladen. Das ganze mit Windows 7 SP 1 und LAN, Intel Core 2 Duo E8200, 2.66 GHz, 4 GB RAM und 64-Bit-System.
Ich weiß, für einen "echten" Gamer sind diese Daten lächerlich, aber mir reichts.

[CrowRoyaL]

Kann mir jemand bei diesem Fehler behilflich sein?

Okt 22, 2016 1:32:01 PM com.sun.xml.internal.ws.wsdl.PayloadQNameBasedOperationFinder <init>
WARNUNG: Nicht eindeutige Textteile. Gemäß BP 1.1 R2710 müssen Vorgänge in einem Port eindeutige Vorgangssignaturen enthalten, damit die Verteilung erfolgreich verläuft. Methoden [getName, userData, getFriendFoe, isLoginAllowed, storeLatency, getTip] haben denselben Anforderungstextblock {http://www.w3.org/2001/XMLSchema}string. Die Verteilung von Methoden verläuft möglicherweise nicht erfolgreich, die Laufzeitumgebung wird versuchen, die Verteilung mit SOAPAction vorzunehmen. Eine andere Möglichkeit besteht darin, AddressingFeature zu aktivieren, damit die Laufzeitumgebung WSDL-Vorgänge eindeutig mit wsa:Action-Header identifizieren kann.
Okt 22, 2016 1:32:01 PM de.deltaga.eb.BasicEventBus publish
INFORMATION: No subscriber for js.java.schaltungen.chatcomng.ChatUser
Okt 22, 2016 1:32:01 PM de.deltaga.eb.BasicEventBus publish
INFORMATION: No subscriber for js.java.schaltungen.chatcomng.ChatUser
Okt 22, 2016 1:32:23 PM com.sun.xml.internal.ws.wsdl.PayloadQNameBasedOperationFinder <init>
WARNUNG: Nicht eindeutige Textteile. Gemäß BP 1.1 R2710 müssen Vorgänge in einem Port eindeutige Vorgangssignaturen enthalten, damit die Verteilung erfolgreich verläuft. Methoden [getName, userData, getFriendFoe, isLoginAllowed, storeLatency, getTip] haben denselben Anforderungstextblock {http://www.w3.org/2001/XMLSchema}string. Die Verteilung von Methoden verläuft möglicherweise nicht erfolgreich, die Laufzeitumgebung wird versuchen, die Verteilung mit SOAPAction vorzunehmen. Eine andere Möglichkeit besteht darin, AddressingFeature zu aktivieren, damit die Laufzeitumgebung WSDL-Vorgänge eindeutig mit wsa:Action-Header identifizieren kann.

[hinz]

Welchem Fehler? Ich sehe hier nur Warnung und Information?

Servus
Heinz