LBS19000303 - Telegram Contact I LBS19000304 - Telegram Receiver I LBS19000645 - Telegram Command Validator

[jonofe]

Das Problem kann eigentlich nur beim Aufruf der externen Library passieren, nämlich hier:

$response = Request::sendMessage($data); 

Denn ansonsten passiert zwischen den beiden Logausgaben

2020-09-17 08:28:30 825218 21760 debug EXE19000303 [v1.1]: Command:text (855)
2020-09-17 08:44:20 461167 21760 debug EXE19000303 [v1.1]: Telegram text message sent: Antwort (9***) (855)

nicht viel, außer pures PHP.
Du könntest mal einen Logeintrag vor und nach dem sendMessage() einbauen.

logging($id,'START sendMessage()');
$response = Request::sendMessage($data);
logging($id,'FINISHED sendMessage()'); 

Wenn dann da die Verzögerung später im Log auftritt, dann passiert es definitiv in der externen Library.
Hast du diese noch mal komplett neu installiert?

[DustinR]

Ich schicke keine automatischen zeitgesteuerten Nachrichten, sondern immer nur, wenn ich vorher meinen Bot etwas gefragt habe. Es ist also jeden Tag zu einer anderen Zeit die erste Nachricht. Und das meistens irgendwas nach 7 Uhr. Es ist auf jeden Fall im Sendeprozess, da ich den Empfang sehen kann und in den Logs ja auch zu sehen ist, dass die Nachricht prozessiert wird, aber erst später gesendet wird.

Erste Nachricht von heute:

2020-09-17 08:28:30 765219 21693 debug LBS19000303 [v1.1]: LBS started (855)
2020-09-17 08:28:30 767445 21693 debug LBS19000303 [v1.1]: LBS ended (855)
2020-09-17 08:28:30 789259 21693 debug LBS19000303 [v1.1]: LBS started (855)
2020-09-17 08:28:30 792001 21693 debug LBS19000303 [v1.1]: Create Message Queue with ID: 391*** (855)
2020-09-17 08:28:30 793358 21693 debug LBS19000303 [v1.1]: command started (855)
2020-09-17 08:28:30 793457 21693 debug LBS19000303 [v1.1]: ================ ARRAY/OBJECT START ================
2020-09-17 08:28:30 793557 21693 debug LBS19000303 [v1.1]: {"text":"Antwort"}
2020-09-17 08:28:30 793657 21693 debug LBS19000303 [v1.1]: ================ ARRAY/OBJECT END ================
2020-09-17 08:28:30 794912 21693 debug LBS19000303 [v1.1]: LBS ended (855)
2020-09-17 08:28:30 804318 21693 debug LBS19000303 [v1.1]: LBS started (855)
2020-09-17 08:28:30 806314 21693 debug LBS19000303 [v1.1]: LBS ended (855)
2020-09-17 08:28:30 823714 21760 debug EXE19000303 [v1.1]: Telegram message execution started (855)
2020-09-17 08:28:30 825218 21760 debug EXE19000303 [v1.1]: Command:text (855)
2020-09-17 08:44:20 461167 21760 debug EXE19000303 [v1.1]: Telegram text message sent: Antwort (9***) (855)
2020-09-17 08:44:20 463234 21760 debug EXE19000303 [v1.1]: Telegram message execution finished (855)

[fisch3009]

Ist denn die 1. Nachricht nach 0 Uhr, auch tatsächlich eine, die irgendwann kurz nach 0 Uhr verschickt werden soll, sprich evtl. ein Problem im Zusammenhang mit der Auslastung von Edomi durchs Datenbanken aufräumen oder kann die 1. Nachricht auch um 5.12 Uhr gesendet werden sollen und kommt dann erst um ca. 5.27 Uhr an?

[DustinR]

Zumindest seit ich das Log 2-3 Woche an habe ist es so, dass es immer die erste Nachricht am Tag ist. Es war aber auch definitiv früher auch mal zwischendurch. Also ja, die erste Nachricht nach 0 Uhr ist aktuell das Problem. Mit der Projektaktivierung hat es nichts zu tun, da ich das vor ein paar Tagen das letzte Mal gemacht habe.

[jonofe]

Was genau bedeutet die erste Nachricht am Tag?
Nach 00:00 Uhr die erste Nachricht?
Oder die erste nach Projektaktivierung?
War es nicht anfangs das Problem dass es immer wieder zu Verzögerungen kam und nicht nur bei der ersten Nachricht?

[DustinR]

Also: 1x den LBS pro Empfänger und dann per iKO den Text darauf senden
Alles andere macht keinen Sinn. Das würde ich erstmal ändern.
Wenn du ähnliche Konstrukte mit anderen LBS hast, dann kann das durchaus die Ursache sein.

Hey, da bin ich mal wieder. Also ich habe alles umgebaut und es gibt jetzt pro Empfänger nur noch einen LBS. Sehe in den Prozessen auch, dass nun nur noch die beiden aktiv sind. Leider hat das absolut gar nichts geändert. Die ersten Nachricht des Tages kommt auf jeden Fall 15-20 Minuten später. Den restlichen Tag funktioniert das nach wie vor sehr gut. Halt am Anfang aber nicht.

Ich habe absolut keine Idee mehr und irgendwie auch keinen Ansatz mehr, wie ich dem auf die Spur kommen kann.

Noch irgendwelche Ideen?

[jonofe]

Also: 1x den LBS pro Empfänger und dann per iKO den Text darauf senden
Alles andere macht keinen Sinn. Das würde ich erstmal ändern.
Wenn du ähnliche Konstrukte mit anderen LBS hast, dann kann das durchaus die Ursache sein.

[DustinR]

Klar. Person A startet das VPN, dann soll auch Person A am Ende die Rückmeldung bekommen. Wenn Person B zwischendurch schreibt, dann muss ich mir die ID von Person A ja immer zwischenspeichern und sie dann am Ende wieder mit übergeben. Wenn ich also auf der gleichen Logikseite mein eigenes "Telegram Contact" habe, dann brauche ich das mit der Zwischenspeicherung nicht machen, weil auf der Seite ja in dem LBS schon die richtige ChatID steht.

[vento66]

Die chat Id ist doch für jeden Empfänger fix...

[DustinR]

Weil ich der Meinung war hier gelesen zu haben, dass es kein Problem ist, wenn man mehrere Instanzen hat. Ich habe mehrere Logikseiten, wo der Baustein verwendet wird, weil die Seiten einfach irgendwann etwas unübersichtlich und auch ziemlich laggy waren. Bei den meisten Seiten mache ich es schon so, dass ich die zu sendende Antwort in ein internes KO stecke und das dann den "Telegram Contact" triggert. Ich bin nur der Meinung, dass das nicht überall möglich ist, wenn es um mehrere Empfänger geht.

Ich habe z.B. eine Logik, die eine VPN-Verbindung starten soll und ich möchte dann eine Rückmeldung bekommen, wenn die Verbindung aufgebaut wurde. Das bedeutet, dass ich nur einer bestimmten Chat-ID diese Rückantwort geben möchte. Wenn ich das aber in einen "allgemeinen" Telegram Contact schicke, dann kann sich die ChatID ja zwischendurch geändert haben, weil eventuell ja Person B auch gerade mit dem Bot kommuniziert. Und ja, ich könnte mir die ChatID in dem Fall sicher auch noch zwischenspeichern, aber mir kam es bisher sehr viel einfacher vor, wenn ich dann einfach einen weiteren LBS habe.

Und zu 90% funktioniert das ja auch sehr gut am Tag. Machen das denn hier alle so, dass sie immer nur einen LBS pro Contact haben?

[jonofe]

Warum 15 Instanzen? Würde nur Sinn machen bei 15 verschiedenen Empfängern. Ansonsten eine Instanz für einen Enpfänger.

[DustinR]

Das mit der Queue war eine Vermutung, denn ich hatte z.B. heute folgendes: Um 15:10 Uhr und um 15:22 Uhr habe ich jeweils meinem Bot eine Nachricht geschrieben, wo es normalerweise eine direkte Antwort drauf gibt. Die Antwort kam dann um 15:25 Uhr für beide gleichzeitig. Da es sich bei der Antwort um die gleiche LBS-Instanz gehandelt hat, dachte ich mir, dass es irgendwie etwas wie eine Queue geben muss.

Die DNS-Anfragen sehe ich in meinem PiHole.

Aktuell habe ich 15 Instanzen vom 19000303 (Telegram Contact). Wenn ich das richtig gelesen habe, dann sollte das aber ja kein Problem sein, dass es ein paar mehr sind?

[jonofe]

Das mit dem gequeued verstehe ich nicht. Welche Queue und wo siehst du DNS Anfragen?

die php Prozesse sind normal. Drück mal 'c' wenn top läuft, dann siehst du zu welchem LBS sie gehören. Jeder LBS der einen EXEC Daemon startet hat einen php Prozess.

[DustinR]

Gestern und heute genau das gleiche Problem. Die erste Nachricht des Tages dauert 15-30 Minuten. Danach sieht das eigentlich immer sehr schnell aus. Hat das wirklich niemand anders? Oder schickt ihr einfach viel öfter Nachrichten? 😀 Ich habe auch einfach 2-3 Stunden mal nichts gesendet und dann wieder versucht, aber das ging dann auch immer. Ich kann also auch nicht genau sagen, nach was für einer Pause das dann nicht mehr funktionieren sollte.

Schon ein bisschen nervig.

Ich mal wieder. Ich habe noch etwas weiter analysiert, weil das Problem gefühlt schlimmer wird. Ich kann sehen, dass die DNS anfragen auch erst durchgeführt werden, wenn die Nachricht auch wirklich an Telegram versendet wird. Wo wird denn da im Hintergrund noch irgendwas gequeued? Oder ist das irgendwie ein Nebeneffekt vom Edomi?

Ist es richtig, dass es so viele schlafende PHP-Prozesse gibt?
top.PNG

VG Dustin

[simonlaessig]

Hmm ich bin jetzt auch mal auf CentOS 7 hoch, beim Telegram bekomm ich

[COLOR=#FF0000][FONT=EDOMIfontMono][SIZE=10px]Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000303.php | Fehlercode: 2 | Zeile: 138 | preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead[/SIZE][/FONT][/COLOR]

Irgendwo vorne stand das ich was abändern muss, aber das ist ja schon in der neuen verison alles richtig. Wie bekomme ich das weg? Hab alle Consolenbefehle die in der Hilfe stehen nochmals ausgeführt

Edit: Scheint zu gehen, hab im Edomi den Baustein nochmal gelöscht und neu installiert.