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
Platform information:
Hardware: Raspberry PI 4 with 4 gb RAM - everything running off an SSD
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?
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…?
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.
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.
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.
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?
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.