Java exceptions after editing DSL rules file

vanja · December 25, 2024, 8:32am

Hi,
Minor issue really, probably due to the nature of the old rules-dsl engine…
Just wondering is there any way to avoid it, as usually I keep my openhab.log clean, no logging there for days, filtered out all irelevant info messages, configured email alerts when error pops up, so its just ugly to get hundred lines exception every time I edit a rule.

I assume the error originates from the fact that I have some timers that get “interrupted” by reloading the file.
Example, after item is triggered, start timer 10 minutes and then do something. so if rule is edited 5min after the timer has started, it messes him up (I guess).
I think the phenomena is not happening if I edit some other rule file where there is no timers, and no rules running at that moment.
Can this be prevented? Can I manually issue a command to stop the running rule before editing? Of course, this error is benign as it never happens again, until the next editing.
Another workaround would be to separate all rules with timers in their own file.

2024-12-19 13:08:36.367 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'scenes.rules'
2024-12-19 13:18:15.650 [WARN ] [ore.internal.scheduler.SchedulerImpl] - Scheduled job '<unknown>' failed and stopped
java.lang.reflect.UndeclaredThrowableException: null
        at jdk.proxy112.$Proxy234.apply(Unknown Source) ~[?:?]
        at org.openhab.core.internal.scheduler.SchedulerImpl.lambda$12(SchedulerImpl.java:189) ~[?:?]
        at org.openhab.core.internal.scheduler.SchedulerImpl.lambda$1(SchedulerImpl.java:88) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
        at java.lang.Thread.run(Thread.java:833) [?:?]
Caused by: org.openhab.core.model.script.engine.ScriptExecutionException: The name '<unkown>' cannot be resolved to an item or type; line 0, column 0
        at org.openhab.core.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:141) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:1008) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:971) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:247) ~[?:?]
        at org.openhab.core.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:227) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluateArgumentExpressions(XbaseInterpreter.java:1222) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._invokeFeature(XbaseInterpreter.java:1152) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeFeature(XbaseInterpreter.java:1098) ~[?:?]
        at org.openhab.core.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:151) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:878) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:243) ~[?:?]
        at org.openhab.core.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:227) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:475) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:251) ~[?:?]
        at org.openhab.core.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:227) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:213) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.ClosureInvocationHandler.doInvoke(ClosureInvocationHandler.java:47) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.AbstractClosureInvocationHandler.invoke(AbstractClosureInvocationHandler.java:30) ~[?:?]
        ... 9 more
2024-12-21 13:29:16.547 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'multimedia.rules'
2024-12-25 00:31:26.549 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'scenes.rules'
2024-12-25 00:39:53.907 [WARN ] [ore.internal.scheduler.SchedulerImpl] - Scheduled job '<unknown>' failed and stopped
java.lang.reflect.UndeclaredThrowableException: null
        at jdk.proxy112.$Proxy234.apply(Unknown Source) ~[?:?]
        at org.openhab.core.internal.scheduler.SchedulerImpl.lambda$12(SchedulerImpl.java:189) ~[?:?]
        at org.openhab.core.internal.scheduler.SchedulerImpl.lambda$1(SchedulerImpl.java:88) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
        at java.lang.Thread.run(Thread.java:833) [?:?]
Caused by: org.openhab.core.model.script.engine.ScriptExecutionException: The name '<unkown>' cannot be resolved to an item or type; line 0, column 0
        at org.openhab.core.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:141) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:1008) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:971) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:247) ~[?:?]
        at org.openhab.core.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:227) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluateArgumentExpressions(XbaseInterpreter.java:1222) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._invokeFeature(XbaseInterpreter.java:1152) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeFeature(XbaseInterpreter.java:1098) ~[?:?]
        at org.openhab.core.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:151) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:878) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:243) ~[?:?]
        at org.openhab.core.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:227) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:475) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:251) ~[?:?]
        at org.openhab.core.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:227) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:213) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.ClosureInvocationHandler.doInvoke(ClosureInvocationHandler.java:47) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.AbstractClosureInvocationHandler.invoke(AbstractClosureInvocationHandler.java:30) ~[?:?]
        ... 9 more

Udo_Hartmann · December 25, 2024, 12:36pm

Well, the point is: the timers don’t get interrupted but stay in the scheduler, but when they finally get executed, the used variables aren’t initialized any longer.
Unfortunately, afaik there is no way to prevent these issues, other than to stop openHAB before saving the rules file or at least ensure that there aren’t any running timers in the edited file when saving the rules file (which will be tricky…).

jimtng · December 25, 2024, 7:56pm

In JRuby, all timers are automatically cancelled for you when the script unloads (reloads), so this problem doesn’t happen there.

This may be usable from within rulesdsl to achieve something similar, but I haven’t tried it myself: [automation] Add script extension to allow scripts to track their disposal by jpg0 · Pull Request #1264 · openhab/openhab-core · GitHub

rlkoshak · December 25, 2024, 11:42pm

If you use the cache to store timers instead of a global variable the timer will be cancelled instead of becoming orphaned like this. This works for Blockly, JS Scripting, Rules DSL or anything using the Java openHAB timer Objects and the cache.

I JS, I believe timeouts and intervals also automatically get cancelled on a reload.

When multiple rules need to access the same timer, it won’t be cancelled unless all the rules that use it are unloaded. If only one rule uses the timer, you should use the private cache.

jimtng · December 26, 2024, 12:25am

Cool! It’s been supported since 2022 and I’ve just known about it now! Is sharedCache working in rulesdsl now? Last I saw an issue saying that it isn’t.

vanja · December 26, 2024, 12:02pm

Well a month ago was still reportedly broken

github.com/openhab/openhab-core

sharedCache broken for rules DSL

opened 10:08AM - 12 Nov 24 UTC

mstormi

bug

The shared cache is no longer available in rules DSL? [The test rule mentio…ned here](https://community.openhab.org/t/unable-to-use-private-cache-in-rules-dsl/143552/5) results in 2024-11-12 11:04:00.271 [ERROR] [ore.automation.module.script.internal.handler.ScriptActionHandler] - Script execution of rule with UID 'x-1' failed: The name 'sharedCache' cannot be resolved to an item or type; line 5, column 27, length 11 in x There's hints on the forum it worked in 4.1 and broke somewhere between 4.1 and 4.2. Related: #3187

So the solution would be, if this gets fixed for rules dsl files, to have a dedicaded rules file for core stuff that you rarely edit, like startup rules, sharedcache…

rlkoshak · December 26, 2024, 3:05pm

My understanding the issue is mainly with file based Rules DSL. I think it works with managed rules using Rules DSL. I’m not sure if privateCache has the same problem as sharedCache for Rules DSL.

I expect this will get fixed at some point and back ported.