Primär fürs Protokoll: mir ist die Tage da was aufgefallen..
Vorab, der Impact ist vermutlich nicht besonders gross aber zu beheben ist es trotzdem:
Szenario 1:
- Widget-Demo, keine der GA's ist im Cache oder lesbar (klar, ist ja so gedacht)
-> Folge: cometvisu beballert das backend unentwegt mit initialen Leseanfragen (&t=0)
-> Fehler: Backend sendet bei Init (t=0) keine Daten, behoben in eibd-clients 0.0.4+nmu19
Szenario 2:
- mindestens eine der GA's ist im Cache oder lesbar, es passiert aber nichts relevantes am Bus.
- cometvisu-client übergibt kein t=60 (oder was auch immer)
-> Folge: cometvisu-client bricht nach 60s (hardcoded) die Anfrage ab und startet eine neue, auch irgendwo so gewollt, das eibread-cgi Backend (hatte) aber nen Default-Timeout von 300s und somit lurchen immer vier eibread-cgi (r) aufm Backend in sinnloser Lauerposition mit CLOSE_WAIT
-> Fehler: Unterschiedliche timeout-Werte; angepasst auf ebenso 60sek in eibd-clients 0.0.4+nmu19
Einzige Frage: geschickter wäre ansich das t=this.maxConnectionAge-1 im CV-Client mitzugeben und das backend sauber mit einem Timeout zu beenden sowie dabei ein neues i= mitzugeben
-> Aber erst nach dem Update von eibd-clients 0.0.4+nmu19, sonst passiert murks weil auch dort gibt das Backend im Timeout-Fall derzeit nichts aus.
Update ist noch nicht raus, erstmal zur Betrachtung, falls ich was übersehe
Makki
Vorab, der Impact ist vermutlich nicht besonders gross aber zu beheben ist es trotzdem:
Szenario 1:
- Widget-Demo, keine der GA's ist im Cache oder lesbar (klar, ist ja so gedacht)
-> Folge: cometvisu beballert das backend unentwegt mit initialen Leseanfragen (&t=0)
-> Fehler: Backend sendet bei Init (t=0) keine Daten, behoben in eibd-clients 0.0.4+nmu19
Szenario 2:
- mindestens eine der GA's ist im Cache oder lesbar, es passiert aber nichts relevantes am Bus.
- cometvisu-client übergibt kein t=60 (oder was auch immer)
-> Folge: cometvisu-client bricht nach 60s (hardcoded) die Anfrage ab und startet eine neue, auch irgendwo so gewollt, das eibread-cgi Backend (hatte) aber nen Default-Timeout von 300s und somit lurchen immer vier eibread-cgi (r) aufm Backend in sinnloser Lauerposition mit CLOSE_WAIT
-> Fehler: Unterschiedliche timeout-Werte; angepasst auf ebenso 60sek in eibd-clients 0.0.4+nmu19
Einzige Frage: geschickter wäre ansich das t=this.maxConnectionAge-1 im CV-Client mitzugeben und das backend sauber mit einem Timeout zu beenden sowie dabei ein neues i= mitzugeben
-> Aber erst nach dem Update von eibd-clients 0.0.4+nmu19, sonst passiert murks weil auch dort gibt das Backend im Timeout-Fall derzeit nichts aus.
Update ist noch nicht raus, erstmal zur Betrachtung, falls ich was übersehe
Makki