Ensure a specific item is loaded from persistence services last

Setup, Configuration and Use Items & Sitemaps
1

In order to prevent rules that run according to a Time cron condition running when items have not been loaded yet after a restart, I have included this bit of code at the top of these rules:

logInfo("Heat Automation","Running global Heat-Automation update")
    if(SystemReady.state != ON){
        logError("System Startup Catch", "Rule execution blocked -- Persistent item states not yet loaded!")
    }else{

here, SystemReady is a Switch-type item that is switched to ON so if this rule attempts to execute before the item states are loaded, the rule does nothing.

Unfortunately, I’ve noticed that this isn’t quite enough: with thousands of items, it has happened multiple times that a rule triggers before all items are restored, but where the SystemReady already was.

Is there any way to ensure this specific item is loaded last? If restoring these items from the persistence service (mapdb) happens alphabetically, would renaming this Item to zzz_SystemReady do the trick?

2

No.

There are “start levels” available to give some indication of boot progress, I don’t think any of them relate to restore-on-startup actions being completed. That is difficult to monitor, since it might involve multiple persistence services.

Individual rules can be made robust (so then who cares about order); test a state for NULL before using it - if it is NULL, it has not (yet) been restored.

Or use your master ‘SystemReady’ Item, but do not restore it - set it ON after a fixed delay started from a system-started rule/

3

Hmm, there seems to be something funky going on here then. According to the docs, there is a start-level available for loading items from persistence, specifically 30:

00 - OSGi framework has been started.
10 - OSGi application start level has been reached, i.e. bundles are activated.
20 - Model entities (items, things, links, persist config) have been loaded, both from db as well as files.
30 - Item states have been restored from persistence service, where applicable.
40 - Rules are loaded and parsed, both from db as well as dsl and script files.
50 - Rule engine has executed all "system started" rules and is active.
70 - User interface is up and running. (planned, not included yet)
80 - All things have been initialized. (planned, not included yet)
100 - Startup is fully complete.

However in practice, this does not seem to match my system: rules load and attempt to run (via cron triggers) before persistent items are loaded. This seems to indicate that this startup order isn’t fixed

4

I’m not at all surprised. Independent Persistence services may take a while to spin up, may be located on another box, etc. I doubt people would want to wait.