HttpUtils_NonblockingGet Warteschlange

[michael.winkler]

Hallo,

ich musste mein Modul 70_NEUTRINO.pm für bestimmte Sat Receiver Boxen auf HttpUtils_BlockingGet umstellen. Leider kann es in bestimmten Situationen zu einen Crash auf den boxen führen wenn die Anfragen über HttpUtils_NonblockingGet kommen. So wie es sich aktuell zeigt hat die Box wohl ein Problem mit der asynchronen Verarbeitung mit solchen Anfragen.

So jetzt zu meiner Frage. Gibt es eine Möglichkeit das HttpUtils_NonblockingGet so einzusetzen dass ich meine Anfrage in eine art Warteschlange stelle und diese wieder synchron abgearbeitet wird?

Gruß
Michael

[rudolfkoenig]

Klar. Du musst nur die Warteschlange und die Abarbeitung selbst implementieren.

[michael.winkler]

Hast Du mir da eventuell eine Vorlage dafür an der ich mich orientieren kann?

[Markus Bloch]

Schau dir mal YAMAHA_BD an. Da ist sowas relativ simpel implementiert.

[michael.winkler]

Schau dir mal YAMAHA_BD an. Da ist sowas relativ simpel implementiert.

Hallo Markus,

die YAMAHA_BD Vorlage hat mir geholfen. Was mir allerdings aufgefallen ist, ist dass der Speicherverbrauch meines Modules extrem angestiegen ist. Wenn ich ein "list devicename" durchgeführt habe ist hier folgendes aufgefallen:

Code Auswählen Erweitern


helper:
     ADDRESS    10.10.0.113
     PORT       80
     RUNNING_REQUEST 0
     CMD_QUEUE:
       HASH(0x69b8b88)
       HASH(0x693ee30)
       HASH(0x4f4c858)
       HASH(0x69b8498)
       HASH(0x4f882a8)



Je länger der FHEM Server läuft um so mehr HASHes sammeln sich hier an. Eigentlich habe ich deinen Code fast 1:1 umgesetzt, von daher gehe ich davon aus dass dein Modul sicherlich dasselbe Problem hat.

Ich habe jetzt in meinem Modul in der ReceiveCommand Funktion noch folgenden Eintrage gemacht, und damit ist dann auch der Speicherverbrauch wieder normal.

Code Auswählen Erweitern


delete($hash->{helper}{CMD_QUEUE});


[Markus Bloch]

Ich habe jetzt in meinem Modul in der ReceiveCommand Funktion noch folgenden Eintrage gemacht, und damit ist dann auch der Speicherverbrauch wieder normal.

Das kann ich so nicht bestätigen. Hier mal ein list <name> meines BD-Players mit YAMAHA_BD:

Code Auswählen Erweitern

Internals:
   CFGFN
   CHANGED
   DEF        192.168.179.36
   FIRMWARE   1.387M0101
   MODEL      BD-S677
   NAME       BD_Player
   NR         186
   STATE      off
   TYPE       YAMAHA_BD
   READINGS:
     2017-07-19 22:13:22   contentType     video
     2017-07-19 22:13:22   currentChapter  4
     2016-01-23 15:01:49   currentMedia    SETUP
     2017-07-19 22:13:22   currentTitle    4
     2017-07-19 22:13:22   currentTrack    0
     2017-07-19 22:13:22   discType        DVD
     2017-07-19 22:13:22   error           none
     2017-07-19 22:13:22   input           Mediacenter
     2017-07-19 22:13:22   playStatus      play
     2017-07-19 22:13:22   playTimeCurrent 00:41:17
     2017-07-19 22:13:22   playTimeTotal   00:00:00
     2017-07-19 22:13:22   power           off
     2017-06-18 22:30:35   presence        present
     2017-07-19 22:13:22   state           off
     2017-07-19 22:13:22   totalTracks     0
     2017-07-19 22:13:22   trayStatus      close
     2017-07-19 22:13:22   trickPlay       Normal
   helper:
     ADDRESS    192.168.179.36
     AVAILABLE  1
     DISABLED   0
     OFF_INTERVAL 30
     ON_INTERVAL 30
     RUNNING_REQUEST 0
     CMD_QUEUE:
Attributes:
   Licht      Gesamte_Wohnung
   alias      BD Player
   event-on-change-reading state
   group      Multimedia
   icon       scene_scene
   model      BD-S677
   room       Wohnzimmer
   userattr   Licht Licht_map structexclude
   webCmd     on:off:play:pause:skip forward:statusRequest

Das wichtige dabei ist die Zeile 607 in der Funktion YAMAHA_BD_HandleCmdQueue($) (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/71_YAMAHA_BD.pm#L607):

Code Auswählen Erweitern

my $request = pop @{$hash->{helper}{CMD_QUEUE}};

Die Perl-Funktion pop() gibt das letzte Element eines Arrays zurück und löscht dieses aus dem Array. => https://perldoc.perl.org/functions/pop.html

Wichtig sei dabei: Die Funktion YAMAHA_BD_HandleCmdQueue() MUSS IMMER am Ende von YAMAHA_BD_ParseResponse() aufgerufen werden, damit weiter Commands, die in der Queue sich befinden anschließend als nächstes sofort gesendet werden. Genauso muss YAMAHA_BD_HandleCmdQueue() ebenfalls IMMER am Ende von YAMAHA_BD_SendCommand() aufgerufen werden, da dort die Queue befüllt wird.

Gruß
Markus

[michael.winkler]

Danke für die schnelle Antwort.

Die letzte Zeile in der Response Funktion ist mir nicht aufgefallen.

Hätte ich Grundsätzlich hier dasselbe erreicht, oder lösche ich mir dadurch alle noch anstehenden Querys?

Code Auswählen Erweitern


delete($hash->{helper}{CMD_QUEUE});


Gruß
Michael

[Markus Bloch]

Damit wird die gesamte Warteschlange gelöscht und anstehende Queries oder Set-Kommandos vom User sind damit weg.

Gruß
Markus