[ECMA 2021] Sometimes rules are throwing errors

After changing all my rules to ECMA 2021 I notice that they either run without an error or start throwing errors like:

2023-03-10 10:43:27.240 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: ReferenceError: "items" is not defined
....

As the rule can run without this error, the reported ReferenceError (“items” is not defined) has to be caused by something else.
I looks my system is getting unresponsive after about 24 hours. After the following restart I always get:


2023-03-10 09:08:58.033 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript;version=ECMAScript-2021' could not be found for identifier: 5eabc24e-31f3-4c06-83b8-8e4704c7a90b

It looks to me as if the behaviour was caused by the move to ECMA 2021 (I do hope this is not the cause).
Any suggestions for further checks, move to a snapshot version or even revert to the older ECMA rules (not really) are higly welcome.

System on Raspberry 4, running openHABian with openHAB 3.4.2 Release Build

The second error first.

I’ve been seeing that on the OH 4 SNAPSHOTS but only after a clearing the cache (e.g. after an upgrade). But after waiting a bit for the system to come up fully (note that the errors eventually go away and rules start working) a restart comes up clean.

It appears to be a timing issue where the rule engine starts and rules are loaded before the JS Scripting add-on gets reinstalled (because of the clearing of the cache).

I’m assuming you are not clearing the cache every time though. Maybe there is something else going on that is slowing down the loading of the add-on.

The first error is possibly related to the second one. If the add-on is not loaded or if the helper library isn’t yet loaded items won’t yet be available and since it’s a rare rule that doesn’t use items most of your rules won’t work. But do these errors go away eventually and the rules start working?

Sadly this error do come back after the rules had been running without error. The first error reported when this occurs seems to be always:

2023-03-11 00:00:57.456 [ERROR] [.internal.OpenhabGraalJSScriptEngine] - Could not inject global script

javax.script.ScriptException: org.graalvm.polyglot.PolyglotException: Java heap space...

For the moment I replaced the ECMA 2021 rules with the ECMA Edition 5 ones (doing the same). I will report what happens during the next 24 hrs.

There was a bug related to the inject global script but that was only on OH 4 snapshots and it was fixed some weeks ago. Are you sure you are on 3.4.2?

This is a heap problem and the initial cause of the other error messages you get. When there is not enough free heap, the injection of the globals fails and therefore items is not available.

How much RAM has your Pi 4?
And can you please tell me your heap usage? You can find it in the openHAB UI (logged in ad admin) under About, Technical information. There should be a blue bar with the values.

Yes, and that is what my system tells when logging onto it via SSH.

@florian-h05
Raspberry 4 with 4GB RAM

Under the blue line I see (translated): "4 processors usable - 57/158 MB memory useable ( german "Arbeitsspeicher "). Which doesn’t like HEAP to me.
Please note that I reverred to ECMA Edition 5, which probably affects the above numbers.

A big thanks to both of you for taking your time to answer!

I think openHAB is in fact displaying the Java heap usage when it says memory usage or “Arbeitsspeicher”. I wonder why openHAB gets 158MB heap space when you have 4 GB of RAM.

Can you please tell me what the EXTRA_JAVA_OPTS line of the /etc/openhab/default file includes?

Might be possible, but I don’t think so. It is known that ECMA 2021 (or more correct: GraalJS, which runs it) takes some amount of memory (at least on openHAB 3.4.x. for openHAB 4 I improved a few things and was able to reduce memory usage and increase speed of script evalutation), which can lead to problems if you have too little heap, and 158 MB heap is really not much.

Are you talking about the file ‘’“/etc/default/openhab”?

# EXTRA_JAVA_OPTS="-Xms192m -Xmx320m -Dlog4j2.formatMsgNoLookups=true"│

In other words, nothing is set as the line is commented out.

Oops, yes.

Can you please add this line:

EXTRA_JAVA_OPTS="-Xms192m -Xmx500m"

This should set initial heap size to 192MB and max heap size to 500MB, which should be fine given that you have 4GB RAM.

Then restart openHAB, tell me what the memory data says and check if the issue persists.

For this test the ECMA 2021 rules should be used, if I’m not mistaken.
Will do now and report tomorrow. .

The reported memory size changed to 41/259MB right after restarting openHAB.
All further observations tomorrow!

Yes

So far no errors observed.
The morning call of the RollerShutter Rule needed some time to start the rule ( is that once for each and every after a restart of openHAB?). This time no errors were observed ( so far).
The used memory listed on MainUI changed to180/483 MB.

Unfortunately, yes. After the first run, the JS scripts/rules run much faster, but first evaluation takes some time due to the injection of the helper library (which has a pretty large codebase). I have improved this in openHAB 4 and it is much faster if you don’t use require.

Looks much better, I think you shouldn’t run into Java heap problems for GraalJS anymore. Please report if any errors return.

1 Like

Thanks for the support!

1 Like

Hi,

I have the same exact issue here since I updated all rules to ECMA 2021. Before the rules ran much faster and my OH 3.4.2 never hang up. Since I changed the rules, their first run makes the system hang at 100% CPU several seconds, but afterwards it works fine - but only some time.

After some days the system gets into 100% CPU again all the time and I get this error in my log:

...failed: org.graalvm.polyglot.PolyglotException: ReferenceError: "items" is not defined

My OH runs under Windows 10. I have plenty of RAM (8 GB), so how can I increase the heap for Java in Windows? In technical data this is shown (I had to restart OH 5 minutes ago):

4 Verfügbare Prozessoren - 53/475MB Verfügbarer Arbeitsspeicher

Thanks!

I misinterpreted the RAM-info in Java heap usage: The first value (e.g. 53/475 MB) does not mean the RAM in usage, but the free RAM left.

I did a lot of testing with my rules today. First I restarted the OH-service. Most rules then had to compile about 5-10s, which is a really long time. With ECMA 5.1 in the past this was very quick in comparison, but ECMA 2021 is extremely slow.

After testing one rule after another suddenly the CPU stayed at 100%, while the rule seemed to be compiled. It took about 3 minutes, then it finished and the CPU went normal. Meanwhile I checked the OH-heap and it was only 2/512 MB, so only 2 MB RAM were left.

Now it seems to me this is the issue. The Java-RAM is way so less. Please, any idea how to set this to a higher value in Windows 10?

Thank you!

Edit:
I found it: …\userdata\etc\openHAB-wrapper.conf

wrapper.java.maxmemory=768

Now I will try it.

Edit 2:
First impression: The initial compile of the rules now is really fast, so this seems to be the right way.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.