FHEM friert ein, wenn WebClient beim Verbinden abraucht

[dero]

Hi,

wenn ich mit einem Phone (etc.) die Seite aufmache und in dem Moment das Device abraucht, friert FHEM für ~10 min ein.

Ich denke, es liegt daran, dass FHEM single-threaded ist und das die Socket-Verbindung nicht ordentlich terminiert wurde und hängt. (Naturgemäß werden tote Sockets erst beim Schreiben erkannt...)

In einem anderen Thread habe ich gelesen, dass es einen Fix für ein ähnlich gelagertes Problem beim Event-Monitor gibt (long-poll).

Gibt's eine Möglichkeit die Timeouts für Sockets zu reduzieren???

dero

[rudolfkoenig]

Bitte konkreter werden, "abraucht" ist zu nebuloes.

Seit ein paar Monaten schreibt FHEMWEB und telnet Daten per select, d.h. ein abwesendes Geraet sollte FHEM nicht blockieren.

[dero]

Abraucht = einfach aus dem Netz verschwindet, ohne alle Connections zu closen. Konkret: ich bin genau beim Öffnen von FHEMWeb aus der Reichweite meines WLANs gelaufen.

ersion $Id: fhem.pl 4099 2013-10-22 20:55:35Z rudolfkoenig $, os linux, user fhem, pid 1961

dero

[rudolfkoenig]

Zu alt.

[dero]

Wann gibt's denn das nächste stabile Release?

[Joachim]

Hier gibts kein stable relase
den tread mal lesen
http://forum.fhem.de/index.php/topic,18363.msg122570.html#msg122570

[dero]

Habe den Thread gelesen.

"Continuous Integration" ist das Zauberwort. Erfordert aber Disziplin...

Bevor sich einer auf den Schlips getreten fühlt: Ich finde FHEM einfach genial und nutze es jetzt auch für meine Alarmanlage. Die Funktionalität ist atemberaubend. Da ist es natürlich schade, wenn man sich auf keine stabilen Releases verlassen kann. Ausgereifte automatische Tests mit guter Abdeckung wären der erste Schritt. Geräte müssten dann als Mock Ups gebaut werden. Ist natürlich extrem aufwändig für so einen Alleskönner...

dero