@Olymp Could you please check whether this change makes your warnings disappear?
I’ll tell you honestly, I did not understand what I should do: (it’s already late, tomorrow I’ll try to understand and tell you in the morning.) I disabled everything that is possible, I think I found the reason for these warnings, this is a miniDLNA server. Thank you for helping!
Correct.
There are no log files written at all (did both changes at the same time), openHAB is still working fine, though.
That’s why I didn’t configure it that way as a default. It will eventually write the log, but possibly only after a few MB of data have piled up - until then, everything is only held in memory (which should make it much faster than if every single line is directly written to disk).
Just my 2 cents after updating and running into similar problems.
Snapshot 1061 started to show strange behaviour after running successfully for weeks.
Harddisk activity would increase to severe levels for no reason, so i decided to reboot.
After the reboot ( still on snapshot 1061) my openhab would not start anymore… UI would show " waiting for UI’s to install". Cleared cache, cleared temp … no succes.
After reading this thread i decided to update to snapshot 1102…used apt-get (running on Ubuntu) to update… hooray… Openhab starts again.
After that i decided to update to the latest snapshot (1114) only to run into the same problems again. No matter what i tried… it would remain stuck at " installing UI’s".
After some investigation i went ahead and cleared my addons folder that still contained JAR files for the Yeelight and Unify binding…Succes!! Openhab starts… i’ve tried several restarts… no errors… all is working fine…
hope this information helps to clear the situation
Thanks for your observations, @snoekieboe!
As you identified the jars in the addons folder as an issue: May I ask you to try this reconfiguration and see whether it solves the issue?
Do you have a link to this issue?
1 Like
I need to update to #1115?
if so, then I updated to openHAB 2.2.0 Build #1115
warnings are available 
but now I know for sure, these warnings appear when the network is running a miniDLNA server.
thankyou for information, this has also fixed for me.
1115 running fine.
This helped me as well. I got jars for zwave, robonect and minecraft bindings. Zwave i cannot live without so I removed the other two and then everything worked. Then I thought I’d check exactly which of them was the culprit so I put them back, first one and then the other with openhab restarts in between. But now all jar files are back and everything is still working like it should, so I don’t really understand why it didn’t work in the first place. Confused…
I did some more testing and found out that the JAR files in the addons folder only create problems if Openhab is started and the binding as defined in org.openhab.addons.cfg still need to be installed.
Once these binding (including the UI and standard packages) have been installed you can put your JAR files back in the addons folder and Openhab will start and run without problems
1 Like
Just for the record: This workaround completely breaks the Tellstick binding. I’m starting to understand why @Kai wouldn’t recommend it 
Yes, I think this is what I have seen in testing too.
I cannot imagine that this could be related. Do you have any proof?
I’m starting to understand why @Kai wouldn’t recommend it
I was just about to recommend it - no not recommend it but to set this as a default. I did some tests with openHAB 2.1 and saw that this never ever did blacklisting of event handlers, no matter how long they block. So with the Karaf upgrade, this seems to be a new behaviour (and the problem of exceeded timeouts had been present before) - by adding this option, we would be back at full 2.1 compatibility. I have created a PR for it, so if you think this is a bad idea, you should veto asap
Sounds as if Felix FileInstall isn’t our friend either Not just the KAR handling is broken, also normal jars cause issues. Can anyone confirm that this is only since the Karaf upgrade? Or were there problems on Karaf 4.0.8 already as well?
To speed up things I’ve set the zwave binding to DEBUG, makes a lot of logging data 
In about 14 hours of log files (30 MB of data) both timeouts
2017-12-06 08:47:49.578 [WARN ] [nal.common.AbstractInvocationHandler] - Timeout of 5000ms exceeded while calling method 'ThingHandler.initialize()' on 'org.eclipse.smarthome.binding.hue.handler.HueLightHandler@7aec67'. Thread 'safeCall-18' (444) is in state 'WAITING'
2017-12-06 08:50:03.906 [WARN ] [nal.common.AbstractInvocationHandler] - Timeout of 5000ms exceeded while calling method 'EventSubscriber.receive()' on 'org.eclipse.smarthome.io.monitor.internal.EventLogger@1b389ce'. Thread 'safeCall-18' (444) is in state 'RUNNABLE'
did not show up anymore.
So what should be my lessons learned? I guess this is not an openHAB related problem, but a problem with my hardware?
Btw, I’m using a RPi3 with 128 GB USB 2.0 SSD Harddisk attached, so there is no sd card playing around.
I need to upgrade from Jessie to Stretch anyway, so maybe it’s time to do a new OS install …
Not more than I’m describing in this issue. I did everything I could to try to get the binding going (restarted telldus-core, restarted the binding, restarted entire openhab, fiddled around with the library path setting) and nothing helped. As a desperate measure I removed the org.apache.felix.eventadmin.Timeout=0 and restarted OH, and suddenly everything was working.
edit: Ok, I’m starting to give up my efforts to understand what’s happening here. I now put the Timeout=0 back and restarted OH and everything seems to be working. I HATE problems that I don’t understand!
edit 2: Nope. Too happy too soon. Another restart of the binding and it’s broken again…
Havin’ problems, too. Haven’t seen this before the Karaf upgrade, and it started some time after I recently added another jar. OH somehow stopped and after that it refused to do anything after its startup sequence. Tried multiple restarts, removed/readded jars until I noticed my ZWave controller thing was gone, in fact ALL of my things were gone.
Had to recreate the controller manually, now it’s working again (I think … still checking).
On one restart occasion, I noticed it keeps loading .items file multiple times ??
FWIW, felix.eventadmin.Timeout=0 was in place before and all the time.
This was with 1099 as well as now with latest #1115.
Confused, too…
Well, it hints at the fact that indeed sometimes the logging framework (log4j2) takes long for writing a single logging message to disk - and requiring more than 5 seconds to execute a logging line in the code is something rather unexpected to all developers… As I have removed the event handler timeout in the distro now, I would prefer to keep the logging configuration the way it is (i.e. to always flush it to disk), because it is rather annoying to see the latest log entries only after minutes, when the logger decides that stuff should be written to the file. We should keep it in the back of our minds though that extensive logging might cause an issue on some platforms and that changing it to use a memory buffer can resolve this.
1 Like
I have changed the Jetty configuration in the latest build #1117. Could you update to this and see if the warnings are gone?