Prozess PREFIX_RequestRead bleibt bei Modul-Update hängen

Hallo, brauche wieder mal eure Hilfe im Zusammenhang mit dem Update meines Modules.

Aktuell wird mittels Timer „UpdateTimer“ alle 5 Sekunden (ist einstellbar) eine Geräte-Abfrage gestartet. Diese liest via ModBus ca. 40 Werte aus dem Endgerät aus. Das dauert ca. 3 Sekunden (kann ich in den PHP-Informationen sehen). Soweit funktioniert alles gut.

Wenn ich nun ein Modul-Update im Store starte, während dem der Prozess JOTKPP_RequestRead() aktiv ist, bleibt dieser für ca. 20 Minuten hängen. Während dieser Zeit ist das Modul blockiert. Danach wird der Prozess wohl von IPS wegen einem Timeout abgeschossen. Im Log wird vom TimerPool „INSTANZNAME (UpdateTimer): Waiting for Script Result timed out“ protokolliert. Anschliessend läuft das Modul in der aktualisierten Version wieder normal weiter.

Wenn ich das Modul-Update starte, wenn der Prozess nicht aktiv ist, wird das Modul ganz normal aktualisiert und läuft anstandslos mit der neuen Version weiter.

Meine Vermutung ist, dass IPS während dem Update dem laufenden Prozess die ganzen Ressourcen wegnimmt (Code, ev. Variablen und Timer), den Prozess selber aber nicht stoppt. Vielleicht kann mir jemand diesen Prozess genauer erklären?

Ich habe schon folgendes versucht, leider ohne Erfolg :banghead:

  • In der Funktion Destroy den Timer mit $this->SetTimerIntervall(„UpdateTimer“, 0) auf 0 gesetzt.
  • In der Funktion Destroy ein sleep(10) eingebaut, in der Hoffnung dadurch das Update zu verzögern, bis der Prozess durch ist.

Nun habe ich aber hier im Forum gelesen, dass Destroy erst ausgeführt wird, wenn die Instanz bereits abgeschossen wurde (war allerdings ein alter Thread und ist vielleicht nicht mehr so). Kann ich den Prozess selber irgendwie noch abschiessen oder ist das ev. sogar ein Bug? Wie macht ihr das in euren Modulen?

Danke für eure Hilfe!

Das klingt sehr nach einem Deadlock der dort passiert. Ich kann dir aber leider nicht genau sagen warum/wodurch der passiert. Meinst du ich kann das irgendwie bei mir nachstellen ohne Gerät? Können wir ggf. eine Debugging Session machen?

paresy

Hallo paresy,

ja, ich kann es auch ohne Gerät (bzw. mit einem nicht erreichbaren/Fake-Gerät) reproduzieren.
Das sollte also bei dir auch möglich sein mit der aktuellen Beta im Store (JoTKPP).

Folgendes Vorgehen:

  • Instanz „Kostal PLENTICORE plus“ erstellen
  • Bei der ModBus-Splitter Instanz eine Fake-GeräteID angeben
  • Bei der I/O-Instanz habe ich aktuell eine gültige IP drin, geht aber vermutlich auch mit Fake-IP
  • In der Konfiguration einen Intervall setzen und eine Geräte-Eigenschaft aktivieren
  • Danach sollte im Log regelmässig eine Fehlermeldung vom Modul auftauchen mit einem ReadModBusError wegen Zeitüberschreitung
  • Damit „funktioniert“ die Instanz und unter PHP-Information wird JOTKPP_RequestRead gemäss TimerIntervall gestartet
  • Wenn man nun während dem laufenden Prozess (dauert bei Timeout ca. 7 Sekunden) das Modul neu installiert, hat man anscheinend denselben Effekt (Prozess bleibt hängen)

Dass das Modul danach blockiert ist, erkennt man daran, dass in der Instanzkonfiguration „Lese Geräte-Informationnen…“ hängen bleibt. Dort würde normalerweise nach einiger Zeit eine Fehlermeldung erscheinen, dass der Gateway vermutlich nicht korrekt ist und der Status der Instanz sollte sich ändern. Sobald der Prozess von IPS abgeschossen wurde funktioniert das auch wieder.

Falls es nicht klappt, können wir gerne auch einmal eine Debugging-Session machen (brauche einfach eine kurze Erklärung dazu).

Danke für’s reinschauen.

Nun konnte ich die Ursache für das Problem auf den folgenden Code einschränken:

$readData = $this->SendDataToParent(json_encode($sendData));

Wenn ich diese Zeile durch folgendes ersetze


$readData = "000000";
sleep(5);

dann dauert der Prozess immer die angegebenen 5 Sekunden. Auch wenn man während dem laufenden Prozess das Modul aktualisiert oder mittels MC_ReloadModule neu startet, wird der Prozess nach 5 Sekunden beendet und die Instanz „funktioniert“ weiterhin (natürlich mit falschen Daten).

Anscheinend wartet der Code also auf die Antwort von SendDataToParent, diese kommt aber nicht mehr und der Prozess bleibt hängen…

Ist dies nun ein Fehler meinerseits oder ein Bug im ModBus-Gateway?:confused:

Ich hatte bisher leider keine Zeit es nachzustellen, aber ich vermute hier eher einen Fehler unsererseits.

paresy

Hatte mich im Dezember schon gefreut und gedacht, das Problem sei behoben. Nun habe ich aber festgestellt, dass es immer noch (oder wieder?) auftritt. Vermutlich hatte ich im Dezember bei meinen Tests & Updates den Timer deaktiviert…

Seither ist es mir aber wieder mehrmals passiert, das bei einem Update des Modules der Prozess hängen blieb.