Open Brainbug01 opened 1 month ago
Sieht so aus als würden noch Aktoinen ablaufen obwohl onUnload schon durchgelaufen ist,
Das Timerhandling wäre m.E. zu reviewen.
a) Es ist sicherzustellen, dass die Routine refreshData keinesfalls längere Zeit benötigt als das unload Timeout dauert.
b) Es wäre sicherzustellen, dass im Falle dass das unload während der Laufzeit der Routine refreshData auftritt nicht am Ende von refreshData das restart timeout erneut gestartet wird obwohl onUnload bereoits durchlaufen wurde.
Eventuell sollte man in onUnload einen "shutdownInProgress" Marker setzen der an geeigneten Stellen abgefragt wird udn die Aktionen beendet - zumindest aber das Starten eines neuen Timers blockiert.
c) Auf den ersten Blick ist nicht zu sehen wo die schedules Oprations beendet werden. Diese müssen jedenfalls bei onUnload sicher beendet werden - spätestens im Compact Mode können diese zu Problemen führen wenn sie nach dem Stoppen des Adapters noch (an-)laufen würden.
Kommt das mit den Fehlern im Log denn nur wenn der Adapter gestoppt wird? Das Log scheint ja von unten nach oben zu laufen, sprich der erste Logeintrag ist bereits Terminating?
Ja ich hab einen Adapter restart ausgeführt. Ich bilde mir auch ein dass der device watcher das System auch träge macht.
Hm device-watcher ist so ein Adapter der je nach Konfig ein Haufen Einzelsubscribes macht, denke das sollte man mal bedenken zu optimieren.
Das Log oben schaut auch so aus als würde der ein Haufen State Updates in Folge bekommen die sich mit der Logik teilweise bis nach unload anstauen was zu den Meldungen führt.
Und ich überwache meiner Meinung nach nicht mal viele Geräte. Fritzdect, Webbrowser, Shelly, Zigbee 99 insgesamt davon 66 mit Batterie.
Wobei ja aktuell keine Probleme da sind. Kein Alpha cs-controller aber der Rest ist Beta.
My assumption is timing. The refresh method checks on startup as it seems if it is unloaded but not sure if also during refresh run. Somit could happen that the db is already gone but still refresh stuff is in progress. Especially when many states are read and such in a loop or such. Would require code check
So yes there are several loops in that refesh that all await state gets and such. So if such a refresh run takes in sum more then 500ms (which can easiely happen on low performance systems or with a higher number of monitored devices/states) then this has an issue.
Options ar: Add into all these refresh loops checks "if unloaded return" or add an higher close timeout. Second option can still get problematic on slow systems with high numner of states because it is unknown how long a refresh takes usually.
Mein System:
Betriebssystem: linux Architektur: x64 CPUs: 4 Modell: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz RAM: 10 GB
lxc unter Proxmox, CPU Auslastung laut Proxmox bei 3%
So yes there are several loops in that refesh that all await state gets and such. So if such a refresh run takes in sum more then 500ms (which can easiely happen on low performance systems or with a higher number of monitored devices/states) then this has an issue.
@Apollon77 Would await block unload? I think that unload code, especially onUnload callback will run in parallel with the refreshData code blocked at several awaits. Increasing the shutdown timer will not help in this case as a successful return from onUnload will cancel the timer an close the db.
Or is this knowledge incorrect?
Maybe there would be a need to wait inside onUnload until the runni g refreshData cycle has finished...
In fact a successful callback from unload adds 200ms or such and then kills DB, right. SO as said ... ideally we would need to add unload checks in all "loops" in the refresh logic that this is cancelled when unload happened
Ich bin auf js-controller 6.0.4 und Fehler vom device-watcher sind keine vorhanden? Am device-watcher wurde ja nichts verändert? Liegt es an den Änderungen am js-controller das keine Fehler mehr da sind?
Update auf den Alpha js-controller 6.0.1-alpha.0-20240529-9dbeeb628 bringt bei mir folgende Fehlermeldungen. Adapter wurde gelöscht und neu installiert.
``