OpenHAB becomes unstable and slow after ECMA 11 rule coding errors

Hi

When coding new rules using the ECMA 11 and I sometimes introduce a syntax error, meaning that the GraalVM can not parse/evaluate the script, then it will throw an exception to the log, i.e. like this:

2022-01-26 16:33:38.800 [WARN ] [.internal.OpenhabGraalJSScriptEngine] - Failed to retrieve script script dependency listener from engine bindings. Script dependency tracking will be disabled.
2022-01-26 16:33:39.450 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: SyntaxError: <eval>:31:6 Invalid return statement
      return
      ^
<eval>:32:4 Expected eof but found }
    } else {
    ^

        at org.graalvm.polyglot.Context.eval(Context.java:379) ~[?:?]
        at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458) ~[?:?]

After that, the script engine or OpenHAB becomes very slow and is often taking several seconds to execute commands / rules, where it usually takes a few hundred milliseconds.
I have also noticed, that the CPU is running at full load.

The only way I can make it happy again, is to restart the service and avoid making coding errors.
I can live with having to restart, but my family is starting to get annoyed with the lights not coming on when they press the button :slight_smile:

  • Platform information:
    • Hardware: Raspberry PI 4 with 4 gb RAM - everything running off an SSD
    • OS: Openhabian
    • Java Runtime Environment: OpenJDK 11.0.13
    • openHAB version: 3.2.0 (from package)
1 Like

Maybe related:

There are a couple more links in that GitHub issue to other forum posts discussing similar issues.

Yes, it sounds very related - thanks!
Looks like the fixes are due for 3.3 release, so I guess that will be what I’m waiting for then.

It looks like that this issue has been solved.
But to wait for 3.3 stable release would not be satisfying. As this will be as usual first in June this year.
What about minor updates, such as 3.2.1? Like we had them for the 2.5 release.
Every month a release version with bug fixes until 3.3 stable version shows up?

1 Like

Would be great with monthly minor bugfix releases, at least for a while…
Having to go upgrading to a potentially unstable snapshot is not preferred, at least not for my use of OpenHab

Tagging @Kai to potentially give that idea a thought…?

No need to, as we do have monthly Milestone releases, which have been tested.

1 Like

Thats great - I can find Milestone releases for 3.0.0 (M1-M5). I can find none for 3.2, so I was assuming there would be none for 3.3 as well.

There had been Milestones for 3.2 and the first Milestone for 3.3 is not far away :wink:

That is great to hear. But, …

This means you would consider a 3.3 Milestone release more stable than the 3.2 stable release?!
Based on my experience in software development I would say a 3.2.x (x > 0) release would fix things
which turned out to be faulty. Based on the 3.2 functionality.

I would expect that a 3.3 release will add new features and new functionality.
Which again means new potential problems. And furthermore is a Milestone build not a build for a stable version. Which some of the OpenHab users rely on in this one. And maybe have to.

A Milestone build is rather meant for testing and hardening stuff. Not for production.

You are turning my words around, this is not what I wrote/meant.
I (we) cosider a Milestone Release (openHAB 3.3M1 e.g.) more stable than an openHAB-3.3-SNAPSHOT.

Changes are always listed in the changelog.

This is absolutely users choice. I fo myself use Milestones for Production and have never seen issues/trouble doing so.

If you look back, we also had patch releases for earlier openHAB 3 versions, so there was never a statement that we will never see such for openHAB 3.2. There might be one published together with the upcoming Milestone, who knows ? I don’t.

Understood. Thank you for clarifying.

I just wondered, since we saw 2.5.x releases regularly every month back in 2020.

But that had not been just patch/bugfix releases…

I’ve written this out before. Maybe I should create a new post I can link to.

OH is pretty much always moving forward. The snapshots, milestones, and releases may not mean what you think they mean in OH. They are just a snapshot in time.

Version Includes Testing Frequency
SNAPSHOT All changes merged into main since yesterday(ish) Unit testing and development testing Daily
Milestone All changes merged into main since yesterday(ish) Older changes have been “in the wild” for a month, newest changes have less in the wild testing Monthly
Release All changes merged into main a week ago One week code freeze Twice a year

An OH Release is more stable in that it doesn’t change except twice a year. It has more testing only in that the bulk of the changes included have been out in the wild for months. But changes less than a month old have no more testing than a Milestone release.

So, if you were to update to a SNAPSHOT version of OH but only do so twice a year, your OH install will be every bit as “stable” as the Release version. It will only have slightly less in the wild testing than the Release version and really just about the same amount of in the wild testing as a Milestone.

Rarely, a really important bug or security fix (e.g. most recently to fix the log4j2 vulnerability) will be back ported to older releases. But for the most part you need to pick up a new version of OH to get a fix.

A Milestone and Release version will usually not be created if there is a known very serious bug. So from that perspective, Milestone and Release versions are slightly less likely to have a major really big bug. But even that isn’t guaranteed.

So the biggest difference between the three is how often you have the option to upgrade and get the latest changes. And that itself comes with a tradeoff. If you upgrade to the SNAPSHOTS a couple times a week, you might be more likely to run into a previously unknown and recently introduced bug. But the number of changes between your last version and the new version will be very small so dealing with any breaking changes is relatively less work because there will be fewer of them. If you wait six months or a year between upgrades, the number of changes between the versions is huge meaning it’s going to be a lot more work to deal with the breaking changes. In short, stable isn’t always better. It all depends on what you are after.

1 Like

Thank you Rich for your detailed explanation.
Based on what you said, I’ll consider using Milestones from now on to fix issues faster.

I’ve updated my 3.2 system to 3.3M1 exactly because of these memory leak issues, what I’ve also experienced when developing a JS2021 module. Now, my JS library is not loaded at all. I’ve re-installed the JS engine, but still nothing. In the log I do not see any error nor warning about JS modules. If I change a file in my JS module, the system is also not printing anything, so it seems it is event not watching the folder.

Any thoughts?

Ok, I think, the answer is in the release notes :slight_smile: BUT my library is still not loaded even from a level higher in the folder structure.

Bug Fixes 11830 JS script engine no longer watches node_modules for scripts

After upgrading my production system to 3.3M2 I now finally started playing with jsscripting again. Unfortunately it seems that the problem persists. After some cycles of updating a script (in a file) and testing it, my system becomes more and more unresponsive and within 10 minutes of experiments will need a restart.

Does anyone else experience this, or perhaps anyone who experience the problem being fixed with M1?

Best regards,
Jacob Laursen

I have noticed, that with the milestone 3 release, the problem is gone. Even after multiple modifications to ECMA 11 rules, the system is still running smoothly.

1 Like