5iver
September 22, 2017, 3:59am
2
Unfortunately, this still seems to be an issue…
opened 11:46AM - 22 Jul 16 UTC
enhancement
Core
Hi all,
in our project we have a lot of event subscribers and registry change l… isteners implemented which are called during startup / shutdown of ESH as a matter of course. In shutdown phase these services will update their model accordingly which results in the problem that the model cannot be re-built after next startup (because the subscribers / listeners have been assumed that the item / thing / link has been really deleted). We should distinguish between event sending / listener notification for adding / removal of items / things / links **during framework startup / shutdown phase and normal runtime.**
For this reason I would like to disable in our project that events are sent / listeners are notified during startup / shutdown. I could imagine two ways to implement this:
1. Providing a `RuntimeStateService` that can be requested in order to get the information if the runtime is started. So for the beginning the service would only consist of a single operation `boolean : isStarted()` and it will be injected as dynamic dependency into the registries (things, items, links, rules). Then I would skip sending events / notification if the service is present and the runtime / framework is not fully started.
2. Each service that requires the runtime state has to implement a `RuntimeStateListener` interface which is tracked by a central `RuntimeStateService` to be provided by solutions based on ESH. As soon as the runtime state has changed to started the service will inform all listeners about this. Once the runtime left the started state again all listeners are informed about this. For the beginning I will implement the new RuntimeStateListener interface by the AbstractRegistry (concrete registries can decide if the runtime state listener is to be provided as a service).
I think that 2 is the only valid option to implement this requirement. In 1 the runtime state service could unregister too early so that the events are sent / listeners are notified again.
What do you think?
…where rules get loaded before everything gets initialized. There is no such configuration as in OH1 to delay the loading. Here is a related topic and the solution I had used:
The temporary manual workaround that I’ve been using for quite some time now… PR for this… thank you!
Since then, I have modified the script (you’ll need to create the prestart directory):
#!/bin/sh
mv `\ls -1 /opt/openhab2/conf/rules/*.rules | grep -v Startup.rules` /opt/openhab2/conf/rules/prestart
echo
echo Launching the openHAB runtime...
DIRNAME=`dirname "$0"`
exec "${DIRNAME}/runtime/bin/karaf" "${@}"
And added a Startup.rules file with:
rule "Alert: System started"
when
System started
then
Thread::sleep(30000)
executeCommandLine("/bin/sh@@-c@@mv /opt/openhab2/conf/rules/prestart/*.rules /opt/openhab2/conf/rules",10000)
logInfo("Rules", "Startup: Rules restored")
end
1 Like
