- √ - This message Entry ... will be lost

[selbstmacher]

Hallo,

ich habe seit dem aktivieren von db4o folgende Meldungen

22:03:25.646 WARN  o.a.cpr.DefaultBroadcaster[:500]- This message Entry{message=Rolladen_EG_Bad (Type=RollershutterIt
em, State=100), type=ALL, future=org.atmosphere.cpr.BroadcasterFuture@1143ad7} will be lost
22:04:07.451 WARN  o.a.cpr.DefaultBroadcaster[:500]- This message Entry{message=Rolladen_EG_Wohn_2 (Type=Rollershutte
rItem, State=100), type=ALL, future=org.atmosphere.cpr.BroadcasterFuture@1178c84} will be lost

Woran könnte das liegen?

[kuschelganxta]

Hi,

die Nachrichten habe ich auch - selten aber ab und an. Db4o nutze ich nicht, es scheint damit nur zufällig bei dir aufgetreten zu sein.

Hast du evtl. noch eine alte ClassicUI/Habdroid/IOS app offen, die evtl. alte Daten abfragen will?

Grüße
Sascha

[selbstmacher]

Ich kann die Meldungen zumindest provozieren, wenn ich in Habdroid Rolladen oder Lichter schalte.
Die Items die er anzeigt sind ja auch schon immer drin und es werden auch immer genau die angezeigt, die ich schalte.

[selbstmacher]

hmm ich habe mal das Persistance für alle (also die Zeile mit dem *) deaktiviert.
Und die Warnings kommen immer noch.
Kann denn keiner sagen warum die kommen?
Das muss doch einen Grund haben.

[peuter]

Kann denn keiner sagen warum die kommen?
Das muss doch einen Grund haben.

Die kommen vom REST-API, welches wiederum z.B. von Habdroid benutzt wird. Tritt daher auch nur auf wenn man Habdroid benutzt.
Mit dem kompletten persistence-Kram hat das überhaupt nichts zu tun.

Der (technische) Grund ist, dass das REST-Binding keinen Broadcaster-Cache benutzt. Dieser ist dafür da Status-Änderungen zwischenzuspeichern für den Zeitraum in denen Habdroid-Client gerade nicht nicht auf Aktualisierungen vom Server horcht, weil er z.B. gerade eine Statusaktualisierung verarbeitet hat und gerade eine neue Verbindung aufbaut.
Ich habe noch nicht den vollen Durchblick wie genau der Habdroid Client mit dem Server kommuniziert, weiß aber das es dort einige Tricks gibt, die vermeiden sollen, das Status-Updates verloren gehen sollen. Dazu wird also der BroadcasterCache garnicht benötigt, daher ist die Fehlermeldung hier ein wenig irreführend. Denn die dort bemängelten Fehler werden auf andere Weise umgangen, wobei das aber auch nicht zu 100% funktioniert, zumindest nach meiner Erfahrung.

Ich hoffe das bringt etwas Licht ins Dunkel, sollte ich was falsches geschrieben habe, möge man mich korrigieren gerade bei den Dingen die zwischen openHAB <-> HabDroid passieren, fehlt es mit dann doch an dem nötigen Grundwissen, das hier beschriebene ist lediglich meine Interpretation.

[selbstmacher]

Danke.
Das passt auch zu meinen Beobachtungen.

Also wirklich nichts um was man sich Sorgen machen müsste.
Ich werde mir aber mal ein Befehl basteln der mir diese Einträge wieder aus den Logdateien entfernt, die machen mich total wuschig.

[peuter]

Ich werde mir aber mal ein Befehl basteln der mir diese Einträge wieder aus den Logdateien entfernt, die machen mich total wuschig.

Besser wäre es wohl das logging so anzupassen, dass der Fehler garnicht in den Logfiles auftaucht.
Dazu müsste man folgende Zeile in die logback.xml einbauen (ungetestet!):

<logger name="org.atmosphere.cpr.DefaultBroadcaster" level="ERROR" />

[selbstmacher]

Ja das ist natürlich noch besser.
Das werde ich nachher gleich mal einbauen.

Edit:
Funktioniert einwandfrei. Sollte man eventuell standardmäßig einbauen