Test js-controller v2.0.x (GitHub)

[smartboart]

@apollon77 said in [Aufruf] js-controller 2.0 Beta Test:

@smartboart denke alles nur Warnungen.

ok danke..hab ich mir gedacht, macht auch keine Probleme. Wenn du oder sonst wer dennoch ne Idee hat wie man diese gyp und nan Warnungen abstellt, gerne her damit.....

[darkiop]

@apollon77

Das ist alles von heute aufm Slave ab dem Zeitpunkt des Redis-Tests:

log_slave.txt

[apollon77]

Sooooooo @darkiop Super Feedback!!

Die 2.0.32 ist auf GitHub, könntest Du alle 4 cases nochmal checken bitte?

Bisher wurden Adapter beim verlieren der States Connection beendet, aber der Host hat nur bei Objects-DB-verlust was getan ... Damit gab es Edge cases. Ist jetzt geändert.

[darkiop]

Danke. Ich schau mal ob ich heut noch dazu komme

[darkiop]

@apollon77 Noch ne Frage, kann ich eigentlich auch über Github eine alte Version ziehen? Also wie müsste ich z.b. vorgehen wenn ich jetzt wieder die 2.0.25 möchte für die es aber keine NPM Version gibt?

[SBorg]

Die Versionsnummer mit anhängen (geht bei allen NPM-Paketen), also npm install ioBroker/ioBroker.js-controller@2.0.25

[darkiop]

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

Sooooooo @darkiop Super Feedback!!

Die 2.0.32 ist auf GitHub, könntest Du alle 4 cases nochmal checken bitte?

Bisher wurden Adapter beim verlieren der States Connection beendet, aber der Host hat nur bei Objects-DB-verlust was getan ... Damit gab es Edge cases. Ist jetzt geändert.

Das war jetzt doch Aufwändiger als Gedacht, siehe TF3

tf_2-0-32.pdf

Mein Log von Heute ging eben auch per Mail an dich raus.

[darkiop]

@SBorg Jep, das kenne ich - hab mich glaub falsch ausgedrückt. Kann ich auch zu einem Zeitpunkt eines Commits springen zu dem es keine Version gibt?

[apollon77]

@darkiop geht nicht. Nur eine npm Version oder aktuellen GitHub Stand. Ansonsten ginge noch ein spezifischer GitHub Commit, was äquivalent zu einem alten Stand wäre.

Wozu brauchst Du die 2.0.25?

[darkiop]

@apollon77 die 2.0.25 musste nur als Beispiel herhalten wie würde der spezifische commit ausschauen?

[apollon77]

@darkiop Ooooohhhkkkkk ...

Bei testfall 3 sieht man das er "restart" aufruft aber scheinbar wieder kein Restart passiert ...

[apollon77]

@darkiop puuuhh da muss ich mal schauen ...

Per Kommandozeile wäre es denke ich Bei zB 2.0.26 als https://github.com/ioBroker/ioBroker.js-controller/commit/2b2bb746da26cd06862a78a4eb1a1cf209e85d3e

dann

npm install ioBroker/ioBroker.js-controller#2b2bb746da26cd06862a78a4eb1a1cf209e85d3e

0 Apollon77 committed to ioBroker/ioBroker.js-controller

2.0.26: fixId fix

[apollon77]

@darkiop Also ich habe es mal nachgestellt und bei mir getestet. Effektiv geht alles korrekt, bei States dauert es ggf nur länger.

Bei mir steht in der Konfig (iobroker-data/iobroker.json) bei states ein

"options": {
      "auth_pass": null,
      "retry_max_delay": 15000
    }

Das MaxDelay 15000 bedeutet das ein Reconnect alle 15s versucht wird. Bei Objects steht im Default nichts, was bedeutet es sind 2s. Das sind mal mindestens die Dinge die für den Controller gelten. Es sollten 18 Connect Versuche gemacht werden ... also wenn Objects weg ist restarted alles nach 12x2=36s (grob). Bei States sind es 4:30min ... das passt zu meinen Ergebnissen. Und bei mir kam dann der Restart ...

[darkiop]

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

@darkiop puuuhh da muss ich mal schauen ...

Per Kommandozeile wäre es denke ich Bei zB 2.0.26 als https://github.com/ioBroker/ioBroker.js-controller/commit/2b2bb746da26cd06862a78a4eb1a1cf209e85d3e

dann

npm install ioBroker/ioBroker.js-controller#2b2bb746da26cd06862a78a4eb1a1cf209e85d3e

Danke. Werd ich ausprobieren.

[darkiop]

@apollon77 Ok, d.h. du hattest nicht die vielen Fehler bei TF3?

[apollon77]

@darkiop wenn du die viele „connection closed“ meinst dann doch. Wenn die 20 Verbindungsversuche rum sind werden alle Kommandos die in der Zeit gewartet haben auf einen Schlag mit einem Fehler beantwortet. Und je nach Adapter werden die dann geloggt. Das wäre ok Weil es ist ja so passiert.

Gibt nachher noch ein Update was die reconnect delay Synct und auf 5s stellt. Dann sollte es besser zusammenpassen. Melde mich

[darkiop]

Ja, die meinte ich - das waren ja auch ein paar Tausend ... das Logvon gestern das ich dir geschickt habe hat ja auch ein MB dadurch

[apollon77]

Soooo, ich habs jetzt (hoffe ich) 2.0.33 auf GitHub. Ich habe alle Testcases meinerseits gecheckt, wäre super wenn Du nochmal könntest.

Das Update hinterlegt die gleichen Default Reconnection-Delay für States und Objects in der Konfig, was dann jetzt 5 Sekunden sind!
Bedeutet: Er versucht ca. 90-95 Sekunden zu reconnecten in 5s intervallen, danach (egal ob States oder Objects weg ist) beenden sich Adapter und Controller und restarten. Dann sollte der controller wieder "lauern" bzw alle 30s restarted werden.

Und ja, wenn die 95s rum sind hagelt es "Connection Close" Meldungen im Log. Würde ich so lassen erstmal. Wenn es zu oft passiert (was es nicht sollte) kann man es erkennen und nicht loggen, aber dann fehlen die Infos das was passiert ...

Danke für Feedback

[darkiop]

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

Soooo, ich habs jetzt (hoffe ich) 2.0.33 auf GitHub. Ich habe alle Testcases meinerseits gecheckt, wäre super wenn Du nochmal könntest.

Testfall 1:
master + slave = alive
master beenden
nicht wieder starten
= iobroker-hwr lauert

2019-10-16 12:45:46.903  - error: host.iobroker-hwr No connection to databases possible, restart                                                                                                                                                                                               
2019-10-16 12:45:46.912  - info: host.iobroker-hwr iobroker _restart                                                                                                                                                                                                                           
2019-10-16 12:45:47.467  - info: host.iobroker-hwr iobroker Starting node restart.js                                                                                                                                                                                                           
2019-10-16 12:45:48.878  - info: host.iobroker-hwr iobroker.js-controller version 2.0.33 js-controller starting                                                                                                                                                                                
2019-10-16 12:45:48.885  - info: host.iobroker-hwr Copyright (c) 2014-2019 bluefox, 2014 hobbyquaker                                                                                                                                                                                           
2019-10-16 12:45:48.886  - info: host.iobroker-hwr hostname: iobroker-hwr, node: v10.16.3                                                                                                                                                                                                      
2019-10-16 12:45:48.888  - info: host.iobroker-hwr ip addresses: 10.3.1.22 fe80::561e:8619:1900:f27                                                                                                                                                                                            
2019-10-16 12:45:48.892  - debug: host.iobroker-hwr Redis Objects: Use Redis connection: 192.168.1.82:9001

Testfall 2:
master + slave = alive
master beenden
20s warten
master starten
= beide wieder verbunden

Testfall 3:
master + slave = alive
redis beenden
einige Minuten warten, wieder starten
= Reconnect nach 2min, wieder verbunden

Testfall 4:
master + slave = alive
redis beenden
paar Sekunden warten
redis starten
prüfen ob States die innerhalb der 40s erzeugt werden nach dem starten von redis verfügbar sind

┬─[darkiop@odin:~]─[13:12:42]
╰─>$ docker stop iobroker-redis

┬─[darkiop@odin:~]─[13:13:45]
╰─>$ docker start iobroker-redis

--> Ich habe keine Werte dazwischen. Habe extra die Entprellzeit runtergestellt damit aufjedenfall kommen - sieht man auch nachdem der Redis wieder da war (nach 13:13:51).

Und ja, wenn die 95s rum sind hagelt es "Connection Close" Meldungen im Log. Würde ich so lassen erstmal. Wenn es zu oft passiert (was es nicht sollte) kann man es erkennen und nicht loggen, aber dann fehlen die Infos das was passiert ...

Die Frage ist dann aber wie groß das Log wird wenn der Redis mal unbemerkt einen Tag oder mehr ausfällt Nach ein paar Minuten hatte ich schon 8MB reinen Text

[MathiasJ]

Ich will ja nicht unverschämt klingen.
Aber könnte man diesen Threat nicht vielleicht schließen?
Ersatzweise dazu gibt es ja diesen:
https://forum.iobroker.net/topic/25692/js-controller-2-0-ab-sofort-im-latest-repo?page=1
Nun muß man sich bei 2 Threats durch wursteln, um (vielleicht) auf die Lösung mancher Probleme zu kommen.