Every Thing in your system has a dispose() method. When OH is shutting down, it calls each Things’ dispose() in series … so OH will not terminate until all such dispose() methods have completed. Therefore the OH specification for addons that implement dispose() is that the method shall complete “fast”. However not all handlers comply with the “fast” specification (maybe because nobody really knows what that word actually means). And the consequence is that if any Thing handler blocks during dispose() then the whole OH shutdown process is delayed. To find out which binding’s Things are blocking the shutdown, you have to one-by-one remove Things from your system and see which are causing the delay…
Is there any logging that I can use to track down the cause, but having said that I don’t have heaps of add-ons.
I’m looking for the best way to disable without causing any problems with my automation setup.
ie if I disable addon hopefully it won’t break my scripts when install them back
Shouldn’t that be changed to be parallel in the first place?
And second, add a (configurable?) timeout for each dispose()?
I believe there’s at least some code parts that complete seem to ignore shutdown.
Such as when parsing large rules DSL files on slow machines like RPi. Actually a shutdown only ever happens after all rules files had been parsed. Maybe parallelizing makes a difference here, too.
Actually while any core developer might be tempted to think this is a low prio thing because OH is supposed to run 24/7, it’s not in fact.
It’s making upgrades and debugging require much more time, and it’s annoying about anyone, users as well as developers.
@wborn Wouter are you aware of this and maybe can provide some more insight ? thanks
2 Likes
I experience the same thing in my docker based setup. I already raised the timeout for my container to a couple of minutes but I never investigated further to get to the bottom of this. I agree however that it is quite annoying 
Just because this statement opened questions in my mind, if a binding has to do something during a dispose, the speed in which that happens won’t always be in their control. For example (one that admittedly many not be relevant to a binding) if there is a buffer that needs to be written to disk before dispose is done, it takes as long as it takes, right?
So while the policy is to exit fast, maybe it really means as fast as possible where that fast may actually take some time if there’s a lot of stuff a binding needs to do to safely close down.
I agree with @mstormi, why isn’t this done in parallel? Even using a thread pool so four or five can be disposing at the same time if issuing a dispose to everything all at once is a problem would improve it tremendously.
For another data point, shutdown on mine (Ubuntu VM running in Docker) takes about 8 seconds. 2 minutes does seem extreme.
I would say do. I will have a look at changing this.
I don’t think I have this issue. Perhaps the addons you use do not properly handle InterruptedException? If threads ignore the exception and keep running the Java runtime keeps waiting for them to properly terminate until the timeout expires. It’s a common issue devs fail to properly handle this exception and add a comment like “ignored” or “this will not happen” because they just want to get something quickly working and only spend time on proper exception handling once they run into such issues. 
There are certainly some addons that have such a fault. I don’t think you can blame the poster for that.
In the meantime I will look into core to see if the shutdown could be optimised. Although that wont fix faulty addons obviously.
@mstormi / @wborn … this is just a quick and dirty suggestion, (as I don’t admit to great knowledge of the intricacies of the core code), but perhaps line 220 should be modified as follows. This would at least cause the disposal of thing handlers and thing handler factories to be done in parallel rather than in series. Or ??
scheduler.submit(() -> removeThingHandlerFactory(factory));
That may cause threading issues during development if you update the org.openhab.core.thing bundle with a new version.