UPNP verursacht OutOfMemory Exception

[DonGyros]

Hall zusammen,

habe seit einer Weile Probleme mit UPNP aus openHAB heraus.
Früher oder später tauchen folgende Meldungen im Log auf und nichts geht mehr:

22:57:50.818 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.818 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.818 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.821 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.819 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.819 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.823 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.823 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.824 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.822 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.832 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.833 WARN o.t.c.DefaultUpnpServiceConfiguration[:300]- Root cause: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.779 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated org.teleal.cling.registry.RegistryMaintainer@117d7 d2 abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.821 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.882 WARN o.t.c.DefaultUpnpServiceConfiguration[:300]- Root cause: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.881 WARN o.t.c.DefaultUpnpServiceConfiguration[:300]- Root cause: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.836 WARN o.t.c.DefaultUpnpServiceConfiguration[:299]- Thread terminated (SendingRenewal) abruptly with exception: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.932 WARN o.t.c.DefaultUpnpServiceConfiguration[:300]- Root cause: java.lang.OutOfMemoryError: unable to create new native thread
22:57:50.832 WARN o.t.c.DefaultUpnpServiceConfiguration[:300]- Root cause: java.lang.OutOfMemoryError: unable to create new native thread

Kennt das Problem zufällig jemand und kann mir sagen was die Ursache sein könnte?

[thoern]

Zu wenig ram. Wieviel memory hat denn dein System?
Gruß, thoern

[DonGyros]

Kann ich mir ehrlich gesagt nicht wirklich vorstellen das die UPNP Sache so Speicher-hungrig ist.
openHAB läuft bei mir auf einem Odroid mit 2 GB RAM.
Da läuft sonst nichts anderes drauf. Habe auch schon die Max-Größe des Heaps auf 1.5 GB gesetzt.

[kkreuzer]

Nee, am RAM liegt's wohl kaum, Du scheinst irgendein Binding mit einem Memoryleak zu nutzen... Die Runtime selbst hat kein Problem, insofern versuche es mal einzugrenzen, indem Du einzelne Addons entfernst.

Grüße,
Kai

[DonGyros]

Werde ich machen, ich denke aber auch schon das ich den Verdächtigen kenne.
Ich habe in den letzten Wochen keinerlei neues Bindings usw. aufgenommen. Das einzige was sich verändert hat ist die Tatsache das eines der konfigurierten Sonos-Devices momentan offline ist. Kann es jetzt nicht zu 100% beschwören aber ich meine das die Probleme ungefähr zu dem Zeitpunkt angefangen haben seit dem das erwähnte Device offline ist. Da das Songs-Binding, soweit ich das richtig in Erinnerung habe, mit UPNP für die Erkennung der einzelnen Devices arbeitet, kann ich mir vorstellen das hier der Grund für diesen Memoryleak zu finden ist.
Sobald ich hier mehr Erkenntnisse habe, melde ich mich nochmal dazu.

[kkreuzer]

Das klingt sehr plausibel - ich meine auch schonmal an anderer Stelle von Memoryleaks beim Sonos Binding gehört zu haben. Wende Dich am Besten an die englische Mailinglist, denn da liest Karel mit, der das ganze implementiert hat.

Grüße,
Kai

[MarcPA]

Status Fehleranalyse SONOS

Hi,

ich hatte mit Karel dazu bereits kurz Kontakt. Bei mir tritt der Fehler unter LINUX auch auf: sobald ich das SONOS binding aktiviere, steigt mit das ganze openhab nach einigen Stunden mit einem out-of-memory aus. Ich verwende eine neue SONOS-Bridge und habe 2x Play 1 und 2x Play 3 im Netz.

Ich habe angefangen, das ganze zu analysieren und festgestellt, dass der Speicherverbrauch des Prozesses ("watch ps -aux") während der Laufzeit konstant wächst, wenn das Binding aktiviert ist.

Daraufhin habe ich mir mit "lsof -p PID" die Liste der offenen Files des Prozesses angesehen und festgestellt, dass der Prozess tausende von offenen Filehandles hat und alle paar Sekunden einer dazukommt.

Wenn man sich das dann genauer ansieht stellt man fest, dass das alles tote Sockets sind, die mit den IP-Adressen meines SONOS-Systems zu tun haben. Diese Sockets sind im TCP-state CLOSE_WAIT, d.h. das SONOS-System hat den Socket mit FIN beendet, aber auf unserer Seite hat der Prozess den Handle noch nicht mit close geschlossen. Der Socket wartet, bis irgendwann aufgeräumt wird. Da das aber nicht passiert, ist irgendwann der Speicher alle.

Ich wollte mir das Binding mal genauer ansehen. Alternativ habe ich darüber nachgedacht, die verwendete zugrundeliegende CLING-1.0.5 mal gegen die CLING-2.0-alpha3 zu tauschen, um zu schauen ob es dann besser wird. Leider komme ich aus der C++-Welt und fräse mich erst langsam in das Thema JAVA, so dass das wohl etwas länger dauert.

Ich habe zu diesem Thema auch logs, aber ich denke das der Fehler klar ist. Wenn wir das close für den Socket an die richtige Stelle bekommen, wird das SONOS Binding auch sofort ohne memory leak funktionieren.

VG,

Marc

[DonGyros]

Oh man, mit der gleichen Problematik hatte ich vor einigen Monaten beruflich zu tun. Ok das erklärt natürlich einiges. Hat Karel zufällig erwähnt ob er das Problem eingrenzen konnte und das beheben wird? Wenn das natürlich ein Problem in der verwendeten Lib ist, wird das natürlich schwieriger.

Ansonsten werde ich versuchen mir das mal anzuschauen sobald ich etwas Zeit finde. Da müssen an sich ja geöffnete Streams, Connections usw. einfach sauber wieder geschlossen werden und gut ist.

[kkreuzer]

Zur Info: Für Eclipse SmartHome / openHAB2 schaue ich gerade nach einer UPnP-Library, die allgemein verwendet werden kann (also auch von einem zukünftigen Sonos-Binding) - leider gibt es kaum etwas brauchbares als Open Source, der wahrscheinlichste Kandidat ist Cling in Version 2 - in der Hoffnung, dass das nicht mit Memoryleaks zu kämpfen hat...

Grüße,
Kai