Not convinced that is all that is wrong. I routinely get this having never cleared cache nor recently updated. Boot up time example
2020-04-30 09:16:49.359 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'New Event Log': The name 'lock_log' cannot be resolved to an item or type; line 125, column 3, length 8
2020-04-30 09:16:49.369 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'New Event Log': The name 'EventLog17' cannot be resolved to an item or type; line 134, column 6, length 10
lock_log is a global object declared at start of file
var java.util.concurrent.locks.ReentrantLock lock_log = new ReentrantLock()
There’s an import just before that of course, but no indication the import fails at xxx.rules load time.
‘EventLog17’ is one of twenty similar String Items defined in an xxx.items file, EventLog00 to 19. It’s really random why one in the middle comes to grief, the rule would have had to process 19 and 18 to discover 17 was missing.
Stranger still, to get there it must have passed the lock_log problem - I do believe the first rule run fails at the lock (it would be attempting to log a bootup message) but the second rule run on another message passes that hurdle.
I’d guess the import is done asynchronously and takes a finite time.
An openHAB stop / start will usually come up clean.
This is happening on a Windows laptop, I expect environment and host performance has a big influence.
Now, this is a development system i.e. it might be off for days and then booted up.
How cache-y is this cache, I wonder?
Does it timeout, become unusable, while system is offline?
I must look into this more closely.
Okay, tried a “hot reboot” from the above situation, those problems cleared of course but instead a new occurrence of an old favourite
"The name 'ON' cannot be resolved to an item or type; line 48, column 24, length 2"
Second “hot reboot” … clean as a whistle.
Alright, now I’m beginning to believe the cache thing and that it is time based.