PluginClient: Exception wenn Sim beendet wird

[duncyo]

Ich weiss noch nicht warum, aber wenn man bestimmte Stellwerke startet (in meinem Fall Hamburg Altona via Sandbox) und wie folgt vorgeht:

• 1. ein Plugin mit dem PluginClient verbindet
  2. Ein Zug sich im Stellwerk befindet (sichtbar==true)
  3. Sim schließen (nicht das Plugin)

bekomme ich folgende Exception (konnte ich mehrfach nachstellen):

(die Ersten beiden Zeilen kommen via printstream, der rest via errorstream)
(Die Exception wird allerdings nicht vom PluginClient via throws weitergeleitet, daher kann ich selbst nichts unternehmen)

Code: Alles auswählen

Line: null
Ex: Content ist nicht zulässig in Prolog.
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Content ist nicht zulässig in Prolog.
	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(Unknown Source)
	at javax.xml.parsers.SAXParser.parse(Unknown Source)
	at js.java.tools.xml.xmlreader.updateDataByString(xmlreader.java:336)
	at js.java.stspluginlib.PluginClient.run(PluginClient.java:307)
	at java.lang.Thread.run(Unknown Source)

Gruß
duncyo

[duncyo]

Die Exception hatte ich auch schon in anderen Plugins, jedoch lang nicht so häufig wie bei mir.
Habs nun lösen können.

Die Exception kommt immer, wenn der Sim geschlossen wird, während gerade Daten durch den PluginClient bearbeitet/aktualisiert werden.
Dies passiert entsprechend häufiger, wenn die Aktualisierung via request_xxxxxx(irgendwas) öfter als alle 30 Sekunden vorgenommen wird.
Ich habe nun einfach alle überschriebenen Methoden des PluginClient in meinem Plugin synchronisiert und der Fehler ist dadurch weg.

Gruß
duncyo

[js]

Das ganze ist eine simple Wahrscheinlichkeitsrechnung. Die Ursache liegt schlicht darin, dass während einer Datenübertragung der Sim beendet wird. Und je öfter man eben Daten abfragt - und somit überträgt - desto eher kommt es zu diesem Fall.

Normalerweise kommt es beim Beenden des Sims zu einer IOException. Die wird dementsprechend auch korrekt abgefangen und führt zum Ende der Client-Loop. Jede andere Exception wird hingegen nur ausgegeben und sonst passiert nichts. Die Alternative ist da wohl nur, bei jeglicher Exception die Client-Loop zu beenden. Andererseits würde dann jeder Fehler in einem Plugin ebenfalls dazu führen. Gezielt nur auf diese SAX-Exception zu gehen würde das nicht wirklich verbessern: Ein XML-Fehler vom Plugin würde dann ebenfalls zum Ende der Loop führen.

So lange aber das Ende der Loop keine Information (z.B. einen Event) liefert, bringt das alles nur eine Verschlechterung. Eine saubere Lösung wäre wohl nur durch einen Ersatz der PluginClient Klasse auf einem Event-Listener-Konzept machbar. Das wäre auch für zukünftige Erweiterungen besser geeignet. Es steigt aber der Aufwand, da man dann nicht mehr einfach vom PluginClient ableiten würde sondern dort pro Event einen Listener registrieren müsste.

[duncyo]

Das ist richtig

Es ist alles einfach das Gleichgewicht zwischen Aufwand und Nutzen. Ich habs ja nun anders hinbekommen und es läuft ohne Schwierigkeiten.

Danke fürs Feedback!
Gruß
duncyo

[duncyo]

Gezielt nur auf diese SAX-Exception zu gehen würde das nicht wirklich verbessern: Ein XML-Fehler vom Plugin würde dann ebenfalls zum Ende der Loop führen.

Ganz weg ist der Fehler durch meine "Lösung" doch nicht. Ich bekomm das zwar noch geregelt (hab da so eine Vorstellung von nem Response-Delay-Timer) aber so ganz sauber ist das auch nicht.

Zu dem Zitat:
Man könnte die Exception ja auch beispielsweise optional abfangen, z.B. irgendwie in Richtung einer (neuen public) Methode setCloseOnSAXexception(boolean b), wonach dann nur bei true die Loop beendet würde.
Da ich durch die Nutzung eures PluginClient auch wie empfohlen gar nichts mit XML in meinem Plugin zu tun habe (und deshalb auch nicht unerwünscht eine Ex. meines Plugins abgefangen werden kann), wäre das für mich ein Jackpot

Gruß
duncyo

[js]

Mich hätte es auch gewundert, wie eine Synchronisierung da helfen sollte.

Die Exception ist auch keine Exception, sondern nur die Ausgabe davon. Sie wird bereits gefangen.

[duncyo]

Ja - mein Verständnis, warum das dadurch "funktioniert" hat, war auch etwas verschwommen

Ich habs nun durch einen eigenen Timer gelöst, der andauernd request_anlageninfo() aufruft und beim nächsten Tick des Timers überprüft, ob was eingegangen ist - wenn nicht kommt einfach close() - funktioniert bestens.

Hier ist dann meinerseits alles geklärt und der Thread kann demnach zu

Danke bis hierhin!
duncyo