maggu2810
commented
5 years ago The #5617 makes reduces the exception by checking the marker variable "open" in front of asynchronous job execution. It is still possible that the instance is "closed" while the asynchronous job is executed. I assume this is the case on your system. You should add some logging statements to track it down. But the question is how it should be solved.
There is one change that should be applied first: call clearQueue as soon as possible in the close method (the next statement after open is set to false). This will ensure the futures are canceled in front of removing stuff.
After that the run() method -- so the asynchronous execution -- should be modified.
Catch the exception and check if the component is still open. If it is not open anymore, there is nothing to do at all. We could perhaps hide the exception. If open is still true, re-throw the exception
mhilbush
I see this occasionally at system startup. I get one of these exceptions for every thing type defined across all the bindings installed in my system (which is somewhere near 1000 thing types, most of which come from zwave).
It doesn't happen all the time, so I suspect it's a timing issue related to order of startup. I'd estimate it happens maybe 30-40% of the time. It doesn't seem to have any adverse effect on system operation.
I'm running OH build 1431, which includes ESH build 316. However, I've been seeing this for a while, so it's not new in this build.
There was a similar issue logged back in May, but the problem still occurs. https://github.com/eclipse/smarthome/issues/5616