Parallelisierung und Einbettung von SVG Plots

[xenos1984]

Mir sind ein paar Probleme bei der parallelen Erzeugung von SVG-Plots mit dem SVG Modul aufgefallen:

Wenn ich plotfork = 1 setze, aber plotEmbed = 0 / ungesetzt lasse, wird manchmal ein falscher MIME-Typ image/png statt text/html ausgeliefert, wenn eine Seite mit Plots aufgerufen wird, und der Browser beschwert sich, dass die Grafikdatei Fehler enthält und nicht dargestellt werden kann. (Dabei habe ich plotmode = SVG.) Das passiert sporadisch, daher vermute ich eine Race-Condition. Dazu ist mir in 01_FHEMWEB.pm ein Kommentar aufgefallen:

Code Auswählen Erweitern

106 # As we are _not_ multithreaded, it is safe to use global variables.
107 # Note: for delivering SVG plots we fork

Das Problem tritt nicht auf mit plotEmbed = 2. Dafür werden dann aber einige der SVG-Plots nicht mehr angezeigt, und es scheint verschiedene Ursachen zu geben:

1. Wenn ich eine Character-Entity wie z.B. ° für das Grad-Symbol ° benutze, die in HTML5 definiert ist, aber scheinbar nicht in SVG:

Code Auswählen Erweitern

XML Parsing Error: undefined entity
Location: http://zeus:8083/fhem/SVG_showLog?dev=svg_climate_temp&logdev=log_climate&gplotfile=climate&logfile=CURRENT&pos=&fw_id=63587
Line Number 279, Column 89:
<text x="12" y="128" text-anchor="middle" class="ylabel" transform="rotate(270,12,128)">&deg;C</text>
----------------------------------------------------------------------------------------^
Ich vermute, das ist nicht in FHEM zu beheben, weil es eine Einschränkung der SVG Spezifikation ist, und ich stattdessen das entsprechende Unicode-Symbol brauche. Falls man doch irgendwie Character-Entities in SVG bekommt, wäre das toll, ansonsten belasse ich es bei einer Beobachtung".

2. Bei manchen Plots taucht dieses Problem auf:

Code Auswählen Erweitern

XML Parsing Error: not well-formed
Location: http://zeus:8083/fhem/SVG_showLog?dev=svg_sysmon_cpu_io&logdev=log_sysmon_cpu&gplotfile=sysmon&logfile=CURRENT&pos=&fw_id=63625
Line Number 371, Column 199:
<polyline id="line_4" decimals="2" style='mask:url(#mask_svg_sysmon_cpu_io); ' x_min="48" x_off="1597266000" t_mul="0.0107408650563085" y_h="236.8" y_min="0" y_mul="217.6" title="Prometheus" scale="<scale>" onclick="parent.svg_click(evt)" class="SVGplot l4" points=" ..."/>
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------^
Da mag er wohl die <> nicht und möchte &gt; und &lt;. Das Problem scheint aufzutreten, wenn im Titel oder Beschriftungen < oder > vorkommen, statt &gt; bzw. &lt;. Das lässt sich also sicher auch eher vom Benutzer beheben als im Code, aber als Beobachtung ist es vielleicht hilfreich.

[rudolfkoenig]

- plotMode=SVG: alles andere ist nicht unterstuetzt. Wenn gplot funktioniert, ist schoen, wenn nicht, auch

- plotFork=1 mit plotEmbed=0: da wird geforkt, und das Ergebnis als ein HTML zurueckgeliefert. Verursacht prinzipielle Probleme, falls nicht alle Sub-Jobs innerhalb von 90(?) Sekunden fertig sind, weil dann Chrome auf der gleichen Leitung den gleichen Request nochmal schickt, was zu Chaos fuehrt. Will diese Kombination eigentlich auch nicht weiter unterstuetzen, es war ein "Nice Try"

- fork und "not multithreaded" ist kein Widerspuch, ich bleibe bei meiner Behauptung, dass deswegen kein Race-Condition entstehen kann. Das vorher beschriebene Problem bleibt aber.

- plotEmbed=2: das ist die Variante, den ich in der Zukunft als Voreinstellung ausliefern will. Damit wird auch kein <embed> Tag verwendet (wie bei plotEmbed=0), die SVGs werden per JavaScript abgeholt und in divs eingebaut. Habe bisher gezoegert es als Voreinstellung zu setzen, da FHEM haeufig auf Systemen mit wenig Speicher eingesetzt wird.

- "HTML5 Symbol tut nicht in SVG":  Da ich nicht anfangen will, die Beschriftung mit CSS zu positionieren und zu drehen, bleibt das auch so.

- "Not well formed": das sollte ich beheben, muss mir noch ueberlegen, wie man dabei rueckwaertskompatibel bleibt.

[xenos1984]

Ich habe jetzt plotfork=1 und plotEmbed=2 (die unterschiedliche Verwendung von Großbuchstaben verwirrt etwas) und alle Beschriftungen auf Unicode bzw. kein < > Symbol umgestellt, damit gibt es keinerlei Probleme mehr. Auch geht das Rendern jetzt erwartungsgemäß schneller. Wenn ich show TYPE=SVG ausführe, bekomme ich alle 46 Plots, die ich definiert habe, innerhalb von ca. 30 Sekunden angezeigt; bei manchen braucht der Sub-Prozess bis zu 10 Sekunden. Aber FHEM selbst blockiert natürlich nicht (mehr). Und htop zeigt, wie nun alle 4 Kerne des RPi4 wenigstens mal etwas mehr tun als in der Nase zu bohren

Das mit der Race-Condition ist nur eine Vermutung, weil es sporadisch auftritt und ich bisher keine bessere Erklärung gefunden habe. Ich könnte das näher untersuchen, aber da es nur bei plotfork=1 und plotEmbed=0 auftaucht, und das wegen möglicher Probleme ohnehin nicht unterstützt werden soll, macht das wohl wenig Sinn.

[rudolfkoenig]

Bei plotEmbed=2 wird plotfork implizit auf 1 gesetzt.