Kompatibilität von Edomi mit neueren PHP Versionen

[jeff25]

huiii nun bin ich auch neuierig... gibts was ganz neues :-)

[gaert]

Das glaub' ich Dir

[Nanosonde]

Mein Schweigen hat durchaus seine Berechtigung - abwarten...

Jetzt bin ich aber neugierig...

[EPIX]

Grundsätzlich verstehe ich den Hype um "neuer=besser" nicht so ganz...
"Alt & bewährt" ist auch ein ganz nettes Konzept - wichtiger wäre mir (persönlich) der Import / Export :-)

[eghetto]

abwarten...

Brace yourself, winter is coming!

[gaert]

Mein Schweigen hat durchaus seine Berechtigung - abwarten...

[Nanosonde]

https://pecl.php.net/package/bcgen

Das Projekt "bcgen" hat einen neuen Owner und ein neues Zuhause.
Ich habe leider nie irgendetwas vom Edomi Erschaffer diesbzgl. gehört. Schade.
Darum beschäftige ich mich nicht weiter damit. Allerdings gibt es andere Entwickler, die sich offenbar weiter damit für ihre Projekte befassen wollen.

[panzaeron]

Danke für die Info, das eine Wort sagt viel aus...

[vento66]

Wenn man zwischen den Zeilen so liest.... https://knx-user-forum.de/forum/proj...92#post1242392

[panzaeron]

gaert Nanosonde
Gibt es Neuigkeiten zu bcgen und EDOMI? Hört sich für mich interessant an, insbesondere das es dann ein aktuelleres CentOS als Basis bedeuten würde...

[Nanosonde]

Teile von EDOMI sind mit bcompiler compiliert. bcompiler ist nur bis PHP 5.3.x lauffähig. Daher ist derzeit keine Änderung in Sicht.

jonofe

gaert

Hallo zusammen,

ich möchte mich nun nach einiger Zeit mit einer kleinen Überraschung zurückmelden: bcgen
https://github.com/nanosonde/bcgen

bcgen ist kein direkter bcompiler Ersatz, sondern ein komplett neuer Bytecode-Generator.
Nachdem mein erster Versuch, bcompiler fit für PHP7 zu bekommen, nicht erfolgreich war in Bezug auf komplexe Skripte mit OOP usw., habe ich ein ganz neuen Ansatz gestartet. Zwischenzeitlich hatte ich auch Kontakt mit einem Autor des bcompiler. Er hatte leider kein Interesse mehr daran, irgendetwas bei bcompiler weiterzuentwickeln.
bcompiler selbst basierte ja auf dem alten APC (Advanced PHP Cache). Er hat mich bestärkt, es mit OPcache zu versuchen.

bcgen basiert auf dem aktuellen Source Code von OPcache (bcgen Code Stand heute ist PHP-7.2.6, im master-branch ist auch schon eine Version für die kommende PHP-7.3 Version, dort sind aber noch nicht alle Änderungen vom bcgen-7.2.6 enthalten. bcgen-7.2.6 ist derzeit meine Arbeitsversion.)
Es ist quasi eine Abwandlung von OPcache mit der Einstellung "file_cache_only".
Das Gute ist, dass OPcache von Zend selbst gepflegt wird. So muss man also nur OPcache im Auge behalten und schauen, ob sich etwas an der Serialisierung/Deserialisierung der PHP-internen Strukturen geändert hat oder nicht.

Ich habe alle Testcases von bcompiler übernommen und ein wenig angepasst, da die Fehlerausgabe bei PHP7 jetzt etwas anders aussieht.
Alle bcompiler Testcases laufen mit PASS durch.

Getestet habe ich bcgen bisher mit PHP-7.2.5 unter Debian Stretch amd64, Raspian Stretch armhf und einem Debian Stretch arm64 für den Raspberry Pi 3.
Vorkompilierte Skripte mit bcgen auf einem PC liefen auch auf dem ARM64 Debian des RPi3.
Man muss sich allerdings für eine Architektur entscheiden: 32-Bit oder 64-Bit.
Vorkompilierte Skripte laufen nicht auf beiden Architekturen gleichzeitig. Die Serialisierung/Deserialsierung der entsprechenden Datentypen ist da leider nicht so flexibel. Manche sind halt entweder 4 Bytes lang (32-Bit) oder aber eben 8 Bytes lang (64-Bit). Das wollte ich auch erstmal nicht umbauen, da der Code sich dann von der OPcache Vorlage entfernt.

Ein Skript, das bcompiler zum Vorkompilieren benutzt, muss ein wenig geändert werden.

Aus

$fh = fopen("example.phb", "w");
bcompiler_write_header($fh);
bcompiler_write_file($fh, "example.php");
bcompiler_write_footer($fh);
fclose($fh); 

wird

bcgen_write_file("example.php", "example.phb"); 

Mehr Funktionen bietet bcgen nicht.

bcgen wird wie OPcache geladen über zend_extension=bcgen.so.
In der php.ini sollte dann noch mind. der Eintrag

[bcgen]
bcgen.enable=1

stehen.

Ich würde mich freuen, wenn gaert mir mal eine mit bcgen kompilierte Version von Edomi unter einem 64-Bit Linux zur Verfügung stellen könnte, damit ich weiter testen kann.

Jedenfalls gibt es jetzt den Grund "bcompiler' nicht mehr...

[jonofe]

Hi Carsten,

zu Frage 1: Richtig.

zu Frage 2: Das habe ich mal für einen LBS entwickelt, der eine blockierende Message Queue im EXEC Bereich verwendet. Man kann es genauso über eine Stop Message per msg_send machen. Sauberste Variante ist Start/Stop via Message ubd im EXEC eine nicht blockierende Message Queue mit usleep, wo dann beim Beenden von Edom aufgeräumt wird.

zu Frage 3:
der Message Type wird verwendet, damit mehr als 2 Prozesse bzw. mehr als 2 msg_receive Statements selektiv Messages aus der Queue entnehmen können. Wenn du z.B. Messages vom LBS zum EXEC ubd auch zu einem PHP7 Script senden möchtest, dann verwendest du z.B. Type 1 für EXEC und Type 2 für PHP. De entsrechenden Receive Statements entnehmen dann nur Messages, die auch für sie bestimmt sind.
Außerdem ann man damit auch Messages priorisieren. Dazu müsste ich jetzt aber selbst noch mal in der Online Hilfe nachschauen.

[saegefisch]

jonofe Hi André,

das Thema MessageQueue (MQ) und Dein Script-Schema - da habe ich nun doch noch Fragen, ich strauchle noch bei der Adaption für "siehe oben". Der MultiCast gehört zum SMA-Themenkomplex aus dem anderen Thema (ModBus) - es wird also demnächst zwei LBS von mir geben: Ein generischer MultiCast (auch nutzbar für SMA EnergyMeter) und ein fast generischer, aber für SMA angepasster ModBus-LBS. Die Sinnhaftigkeit/Nutzen der MQ-Lösung ist mir mittlerweile klar und möchte ich daher begreifen und selber richtig nutzen.

Zur Info/Rückmeldung:

• Für das Logging im externen Scripten habe ich mich von Deiner Datei-Lösung gelöst und finde es hilfreicher, die LOG-Infos einfach per MQ zum EXEC-deamon zurück zu senden und dort in das reguläre Custom-Log notieren zu lassen = direkt in edomi an einer Stelle sichtbar. Das klappt an sich gut (meine MQ-Probleme liegen woanders; siehe Frage).
• Die von mir erwähnte Zähigkeit mit der MQ habe ich nun ergründet - und ist ganz natürlich: Im externen Script habe ich natürlich auch ein usleep (mit Zeiten bis 15s) und in dieser Zeit wird natürlich kein "stop" oder anderes verarbeitet. Schön Last-schlank, aber doof... Das externe Script muss aber nix aufräumen und werde ich per kill beenden, wenn es nach 500ms nicht reagiert hat (also vermutlich meist).
• Insgesamt kommt die empfundenen Zähigkeit mit der MQ aus den usleep-Zeiten... vielleicht muss man zwei usleep-Schleifen schachteln, die Innere bleibt für die Logik mit ggf. erheblich längeren Pausen und eine Äußere eher hochfrequente (z.B: 500ms) für das Lauschen auf der MQ und eben die Innere.

Fragen:

• In "function LB_LBSID_exec($id, $action = false)" beendest Du den EXEC-Teil per kill. Das heiißt doch aber, dass die übliche Code-Strecke nach dem Main-Loop zum sauberen EXEC-Abwickeln inkl. "sql_disconnect" nicht durchlaufen wird, richtig?
• Welchen Grund gibt es dafür, es nicht im deamon-Schema von Christian (mit usleep) zu lösen? Ich bin mir sicher, Dein Beweggrund ist wie immer wohl bedacht...
• MQ: Irgendwie löse ich es wohl gerade falsch beim start: Wenn ich dem externen Script 7 Werte übergeben will, tröpfeln die nur ein und mach' da wohl noch was falsch (abgesehen vom usleep-Thema; siehe oben).
  Mache ich das in 7 msg_send-Zeilen mit dem selben msgtype (z.B. "1") oder mit 1-7 oder "irgendwie" in einem msg_send? Auf dem Rückweg der Ergebnisse stellt sich die selbe Frage für mich. Letztlich will ich per MQ übertragen:
  - bis zu 7 Parameter EXE -> extern versenden,
  - bis zu 5 Ergebniswerte extern -> EXE,
  - LOG-Rückmeldungen extern -> EXE (2 verschiedene Log-Level).
  Derzeit nutze ich msgtype=1 für Parameter, 10 für Ergebnisse und 11 und 12 für die LOG-Rückmeldungen. Ist das sinnvoll oder habe ich das Prinzip der MQ-Verwendung noch nicht sauber verstanden? der msgtype ist doch gewisserweise ein "Kanal" in einer MQ, richtig?

Danke und viele Grüße,
Carsten

[jonofe]

Ja das sollte funktionieren.

Ein bischen tricky ist immer das Löschen der Message Queue beim Beenden von EDOMI. Das funktioniert auch in einigen meiner LBS noch nicht korrekt.

Wenn der LBS explizit gestoppt wird (z.B. über einen Eingang), dann beende ich den EXEC Daemon mit posix_kill() und lösche die Message Queue im LBS Bereich. Das ist okay.

Wenn aber EDOMI beendet wird (z.B. per Admin Interface), dann bekommt der LBS-Teil das nicht mit und kann auch dem EXEC das nicht mitteilen.
Allerdings wenn der EXEC Daemon in einer while (getSysInfo(1)) Schleife läuft, dann wird die Schleife beim Beenden von EDOMI verlassen und man kann danach explizit die Message Queue löschen. Auch ok!

Problemfall: Läuft allerdings die Message Queue im EXEC Daemon im Blocking Modus, dann funktioniert auch dieser Ansatz nicht. Blocking heisst hier, dass das msg_receive() solange blockiert ist, bis eine neue Message vom LBS Bereich kommt. In diesem Fall bleibt die Message Queue nach dem Beenden von EDOMI bestehen, und zwar bis zum nächsten Reboot des EDOMI Servers oder bis man sie per "ipcrm" löscht.

Da es aber nur wenige Bytes sind, die in einer solchen Message Queue "hängenbleiben" ist das unkritisch.

[saegefisch]

Okay, dann werd' ich das mal die Tage die incode-Kommentare noch schöner machen und es einstellen.

Noch eine Frage: Durch die eindeutigen MessageQueueID sollte es doch problemlos sein, das selben Daemon-Script mehrfach aufzurufen, oder?
HIntergrund wäre: Ich möchte - wenn möglich - aus einem Multicast-Strom einen Werte (=1KO) in hoher Frequenz, aber andere reichen mir alle 15 Sek. Dann könnte man ja den Control-LBS mit dem selben Daemon-Script zwei mal starten mit unterschiedlichen Paramtern und Frequenzen.