This came out on a local OH users groups on FB where one user noticed his installation hanging from time to time without a clear reason.
The reason was actually quite unexpected: open CLI, run log:tail and select some text in the console window. This makes OH hang as long as the text is selected.
Now, I am sharing this as it is an interesting and unexpected behaviour. It looks like EventLogger implementation of EventSubscriber is blocking the event receive() call on logging. Would that be that Windows implementation of logging is not buffered and can be blocked by simply putting the CMD window to a text mark mode? And this seems to put the whole event dispatch loop on hold, so no state changes can occur during this time.
It seems not a really dangerous case, but something internally is telling me this is just wrong that a user behaviour like that in a totally separated subsystem can actually block the core of another subsystem (e.g. channel state updates).
This might be an issue that has more to do with Karaf rather than openHAB itself. log:tail and logging for that matter is provided by Karaf, not implemented by openHAB. And it is Karaf that controls the threading and running of all the bundles that make up openHAB. So if stopping the logging in the Karaf console blocks everything from running, it’s most likely caused by something outside of OH’s control.
I see. This happens only on Windows. On Linux you can stop the console process and the logs will be buffered. But this is really blocking on a call to logger. I have no idea though how Karaf intercepts the logs to show them on console. Thanks.
Then this points to the problem more likely being in Java Runtime for Windows itself than even Karaf. Or it’s just how Windows works. Keep in mind that when you open the Karaf Console, you are doing so through cmd or PowerShell. It would not be unexpected to me that when you have Scroll Lock engaged in those terminals it stops the program outputting to that shell instead of caching the outputs until scroll lock is turned off. Given that it’s the exact same code running in Windows and Linux and the fact that it doesn’t block anything in Linux points to this being a really low level Java Runtime or Windows specific issue that OH will never be able to address.
The logger configuration (userdata/etc/org.ops4j.pax.logging.cfg) has a Karaf console logger and appender configuration.
I think it may be a matter of expectations from the underlying services. If OH expects that the logger implementation is asynchronous and returns control to the event dispatcher as soon as possible, then it is not a valid assumption and it lies outside of the OH control. The question, though theoretical, is that should OH protect itself against this, for example by detaching the internal event processing (in control) from external event processing (out of control), so that even if logger is blocked, internal jobs do not suffer.
That sounds like it could be a lot of development work for a platform that is not the primary focus of OH. As always, you are free to volunteer, though
OH uses the logger that Karaf presents to it. The behavior of the logger is controlled by that config file.
And if this were something that OH had control over, I’d expect the same behavior in Linux and Windows since it’s the same code running with the same configuration. The only difference is Windows. If this were caused by an OH expectation, I’d expect the logger to hault in Linux as well.
But you can experiment with the config and set up an asynchronous appender in the config and see if makes a difference. It doesn’t seem based on the evidence so far, that it would make a difference.
umm - do we really not have windows people here? This is pretty much standard behavior since the early days of the console. Essentially - if you pause the output (whether directly or through highlighting something or a few other ways), the background app will continue to process UNTIL it tries to write to the console - the it becomes blocked as well. Pretty standard behavior for windows from forever (ie backward compatibility) and no surprises with this report. If you don’t like that behavior - try out the new windows terminal which does not do this…
