Fix network timeouts in template tests

[GrimmiMeloni]

Make test suite complete fast again.
Fixes issue introduced in 31ab90e

As a side effect, the problem regarding the 192.0.2.x network being unreachable also disappear, giving me 100% success rate for the test suite locally. My (unconfirmed) theory is, that the tests running in sequence gives some of the heartbeats for different templates enough runtime to actually bump into that issue. By running in parallel the overall test suite is already done by the time the first heartbeat would trigger, so the problems disappear.
We might want to keep this theory in mind, in case we ever see these kinds of heartbeat problems appear as the test suite and its runtime grows.

[andig]

Funktioniert bei mir lokal leider nicht- ich laufe weiter in 10min timeout. Das Basisproblem für die Nicht-Parallelität hat sich leider auch nicht aufgelöst:

=== NAME
    testing.go:1465: race detected during execution of test

Ich fürchte, so einfach ist es leider nicht :(

[andig]

Depends on lorenzodonini/ocpp-go#232

[andig]

Ocpp ist drin und rebased.

[GrimmiMeloni]

Ocpp ist drin und rebased.

Ich sehe unabhängig von meiner Änderung (habe lokal testweise reverted) immer noch die OCPP Fehler bzgl. multipler Registrierung von Chargepoints.

[andig]

Magst du mal Log teilen?

[andig]

Haha. Ok- die OCPP Templates triggern auch gegen den lokalen Server des anderen Tests. Sehr lustiger Seiteneffekt, das lässt sich sicher verhindern. Aber wo kommen die 3min her? Ich verstehs einfach nicht :/

[GrimmiMeloni]

Ich habe gestern mal die charger tests mit Trace laufen lassen.
Die Zeit verlieren wir anscheinend beim Warten auf Netzwerk.

Kannst Dir ja auch mal das Attachment via go tool trace trace2.out anschauen.
Speziell die GoRoutines Analysis, vom tRunner (siehe http://127.0.0.1:52748/goroutine?id=4305110307 , Port musst du anpassen)

trace2.out.zip

[andig]

Die Zeit verlieren wir anscheinend beim Warten auf Netzwerk.

Genau das verstehe ich nicht- denn wir sollten ja parallel warten?

[GrimmiMeloni]

Ich vermute aktuell, daß viele (alle?) auf diesen Mutex in Modbus warten.

https://github.com/evcc-io/modbus/blob/d9fefd3ae5a5d533018460e92b932737e56dbe5e/tcpclient.go#L162

Soweit ich den Code durchforstet habe, sehe ich das modbus/modbus.go (in evcc) connections cached und wieder verwendet wenn eine bekannte URI präsentiert wird.

evcc/util/modbus/modbus.go

Line 235 in a3a15b8

func registeredConnection(key string, newConn meters.Connection) meters.Connection {

Wenn zum testen immer die gleiche URI (192.0.2.2) verwendet wird, wird die neue Connection die in den Konstruktoren der einzelnen Templates entstehen verworfen und stattdessen die vorhandene rausgegeben, so daß dann am Ende alle Tests sich den TcpConnector (und somit seinen Mutex) teilen.

Wie gesagt - working theory. Ich habe zum ausprobieren mal das Caching rausgeschmissen. Das beschleunigt die Tests bereits um Faktor 3. (38s-53s vs 180s). Irgendwo da ist was im Busch.

[andig]

Ich vermute aktuell, daß viele (alle?) auf diesen Mutex in Modbus warten.

AUTSCH! Ja, die These teile ich. Ohne das Caching hast Du dann allerdings wire-level chaos. Das wird m.E. nicht funktionieren; mindestens nicht bei Geräte die nur eine Verbindung zulassen.

Wir könnten sowas wie ein Caching des Verbindungsstatus mit einführen wo- wenn die Initialverbindung fehlschlägt- der Rest sofort abbricht. Aber das nur für die Tests zu machen?

Oder: in Tests wird 192.0.2.2 (haben wir ja standardisiert!) immer auf einen lokalen Port umgebogen der schnell mit Ablehnung antwortet. Das sollte die Tests deutlich beschleunigen (gefällt mir viel besser!).

[GrimmiMeloni]

Wir könnten sowas wie ein Caching des Verbindungsstatus mit einführen wo- wenn die Initialverbindung fehlschlägt- der Rest sofort abbricht. Aber das nur für die Tests zu machen?

Nein, nicht für die Tests jetzt viel umbauen. Auch das Caching zu entfernen ist keine Lösung. Das war wirklich nur reingehackt um zu sehen das die Waits verschwinden.

Oder: in Tests wird 192.0.2.2 (haben wir ja standardisiert!) immer auf einen lokalen Port umgebogen der schnell mit Ablehnung antwortet. Das sollte die Tests deutlich beschleunigen (gefällt mir viel besser!).

Ja, die Tests auf ein vorhandenes(!) Interface zeigen zu lassen (localhost?) wäre generell gut. Dann verschwindet hoffentlich auch die "noise" von den scheiternden Heartbeats.
Zusätzlich sollten wir hier verhindern das die Tests parallel laufen. Wenn die zügig (< 1s) durch sind, können die auch ruhig sequentiell laufen, dann müssen wir an dem Modbus Stack nichts ändern.

Wo wir schon dabei sind - nimmst Du mich auch nochmal an die Hand, und zeigst mir wo die 192.0.2.2 tatsächlich herkommt? Egal wie ich es drehe, ich finde keine Spur von dieser hart codierten IP (außer in den Doku templates). Das kommt vermutlich aus irgendeiner Dependency?

[andig]

Das ist in der defaults.yaml der example Wert für host. Können wir einfach über search/replace ersetzen. Dann müssten wir aber vmtl. überall auch port mit einführen damit war das auf einen einheitlichen Port umbiegen können, sonst wäre das 502, 1502, 80, 443 etc ja nach Testfall. Da hab ich noch keine so gute Idee.

[GrimmiMeloni]

Port ist egal. Es reicht bereits die IP Adresse in der defaults.yaml durch 127.0.0.1 und den hostname durch localhost zu ersetzen. Die Tests sind dann in 4 Sekunden durch. Ich habe das gerade mal gepusht (inkl. einem Revert von meiner ursprünglichen Änderung am Test).

Was mir aber nicht gut gefällt: Durch die doppelte Verwendung der Example Werte als default, haben wir jetzt eigentlich auch ein deutlich schlechteres (weil praxisfremdes) Beispiel. Gibt es eine Möglichkeit den Beispielwert getrennt vom Default zu beeinflussen?

[andig]

Nur wenn ein Default gesetzt ist

[GrimmiMeloni]

Ich habe jetzt mal einen default eingeführt. Der zieht auch, also für die Tests gut.
Aber das bedeutet vermutlich, das jetzt ggf. bei fehlendem Parameter in der Konfiguration dieser Defaults angewendet wird.

Das wiederum würde aber bedeuten, daß bei Fehlkonfigurationen evcc ggf. nicht mehr meckern kann weil ein Wert fehlt, und stattdessen munter die Hardware auf Localhost vermutet wird. Volker wird sich bedanken...

Können wir noch über einen anderen Mechanismus das Verhalten zur Laufzeit während der Tests verändern? Oder ist es deiner Ansicht nach OK, wenn wir das Example wie in af2457b verändern?

[andig]

Statt Default einfach strings.Replace() über das ausgefüllte Template? Dann fehlt allerdigns immer noch der Port und ein Testserver.

[GrimmiMeloni]

Statt Default einfach strings.Replace() über das ausgefüllte Template? Dann fehlt allerdigns immer noch der Port und ein Testserver.

Port und Testserver sind kein Problem. Es reicht einfach den Example Wert der als Default gezogen wird zu übernehmen. Damit hängen die Tests nicht mehr (wie auch beim geänderten example Wert).

Was noch übrig ist, sind die OCPP Tests. Die sind hier aber erstmal nicht direkt involviert, oder?

[andig]

Könnte immer noch lokal was auf 80 oder 502 laufen? Lieber doch den Port noch setzen? Dazu einen tcp listener, der immer sofort die Verbindung schliesst?

[GrimmiMeloni]

Hmmm. Während der Tests gehen 2 random ports auf, und zusätzlich der hart codierte 8887. Letzterer kommt wohl aus dem OCPP Umfeld. Herkunft der ersten beiden ist unklar.

Insbesondere auf 80 oder 502 wird jedoch nichts gestartet. Ich deute dies so, daß aus den Tests heraus auch nicht versucht wird auf diese Ports zu verbinden. Wenn doch müßte es eigentlich Fehler wie Connection Refused geben.
Warum jetzt ein ungültiger hostname (bzw. eine im Netz nicht routebare IP) hier für mehr Verzögerung sorgte als ein geschlossener Port, ist mir nicht ganz klar.
Aus meiner Sicht ist das so OK.

[andig]

Insbesondere auf 80 oder 502 wird jedoch nichts gestartet. Ich deute dies so, daß aus den Tests heraus auch nicht versucht wird auf diese Ports zu verbinden.

Ich denke die Tests versuchen genau das. Und das tun sie weil wir die Ports nicht ändern.

Wenn doch müßte es eigentlich Fehler wie Connection Refused geben.

Gute Frage. Not sure...

[andig]

Auf jeden Fall ists jetzt schnell. Die racy Modbus Tests machen zumindest nix offensichtlich kaputt.

[GrimmiMeloni]

Gerade mal gesynct. Die ocpp tests flutschen jetzt auch durch. make test liefert somit jetzt auch wieder ein RC 0.
Rein damit.