Wouter… you sir are a flippin’ rockstar!!!
Looking at the JVM bug - would it be possible to swap collection implementation to another queue type? This way we do not need to wait for release of JVM.
Yes that would be the way to work around it. Maybe replace the buggy Java 17 implementation with the working Java 11 implementation. But it needs to be done everywhere the class is used. That seems to be openhab-core and jupnp for now. But it could also be used in add-ons or their dependencies.
I made some bundles with patches to use the Java 11 LinkedTransferQueue on Java 17.
This will only work with OH 4.0.1.
Maybe someone wants to test it?
You can update the bundles on the Console with these commands:
bundle:install -s https://github.com/openhab/openhab-base-fixes/releases/download/base-fixes-20230809/base-fixes-1.0.0-SNAPSHOT.jar
bundle:update org.openhab.core https://github.com/wborn/openhab-core/releases/download/base-fixes-20230809/org.openhab.core-4.0.1-SNAPSHOT.jar
bundle:update org.jupnp https://github.com/wborn/jupnp/releases/download/base-fixes-20230809/org.jupnp-2.8.0-SNAPSHOT.jar
The org.jupnp update is optional as it may fail if you don’t use any add-on that depends on it.
After updating the bundles openHAB needs to be restarted for it to work again.
To revert the changes use these commands:
bundle:uninstall org.openhab.base-fixes
bundle:update org.openhab.core https://openhab.jfrog.io/artifactory/libs-release/org/openhab/core/bundles/org.openhab.core/4.0.1/org.openhab.core-4.0.1.jar
bundle:update org.jupnp https://repo1.maven.org/maven2/org/jupnp/org.jupnp/2.7.0/org.jupnp-2.7.0.jar
Then again restart openHAB.
10 Likes
Good job! For convenience of the willing, perhaps you could also provide the commands for reverting back to the bundled version to be prepared in case of severe issues and/or before upgrading to 4.0.2?
They’ve been added to the post now.
2 Likes
Do I need to Install java11 again?
No keep using Java 17, my changes bring some code that did not have these issues from Java 11 to Java 17.
How do I know if I use an binding which uses jupnp?
You can check if the org.jupnp bundle is installed:
openhab> bundle:list -s | grep org.jupnp
245 │ Active │ 80 │ 2.7.0 │ org.jupnp
One more last question…just for my interest…what is the callsafequeue doing in openhab3 exactly?And what is the issue here? Also it’s fine if you can explain it in simple words.
SafeCaller is a construct in openHAB core that all parts of openHAB can use to wrap something in to prevent it from taking too long (or getting stuck forever). Some more basic examples would be when a rule is executed, when a request is made to an external service, etc. It’s a queue because the main code just adds a task to the queue to run on a different thread, and then when it’s done (successfully or not) the original code can continue.
5 Likes
Thanks Wouter
I have installed the patched bundles as per your instructions above after updating to 4.0.1
My case is one of the most easily reproducible with this issue so it won’t take to long to know if it is working. So far, update went well, everything is running smoothly on 4.0.1 after the update. All Jruby rules re-enabled and fingers crossed
2 Likes
So far, this is working great for me. I was having issues with items-queue thread.
1 Like
this patch is a huge step wrt performance.
Now RasPi2 got usabel again for OH4
Thx!
1 Like
@wborn - how do you interpret Doug’s latest comment in the PR. “Yes, it’s possible” - or “yes, I’ll do it”? 
In either case, do you know if it will be possible for us to merge the Java 11 version of LinkedTransferQueue into our repository without any license problems/conflicts? I’m wondering if we could do this at least in 4.0.x, as the tests so far looks positive.
Meanwhile I had a look at how OpenJDK operates and it looks like other devs typically do the cherry picking of fixes.
If you think openHAB has a formal process, you haven’t seen theirs yet.
Fixes first go to jdk17u-dev and then to the actual update repo jdk17u. So you can monitor the PRs of those repos to see if it gets cherry picked.
OpenJDK uses GPLv2 so that’s why I already put the code for the bundle in a separate repo.
2 Likes
If it were cherry picked and merged today it would still take some time before it gets released:
- Tuesday, October 17 2023 GA; OpenJDK 17.0.9 released (tag: jdk-17.0.9-ga)
After that it may take more time for Debian/Zulu/Temurin to release builds.
It seems nothing more will happen automatically according to the process:
https://wiki.openjdk.org/display/JDKUpdates/How+to+contribute+or+backport+a+fix
So I guess Doug was just giving guidance to whoever would pick up the ball and contribute a backport.
From your link there’s also this note in the “Contributing” section:
Should you not be willing or not be able to drive a fix into JDK 17 updates, you can still suggest changes by dropping a mail to the jdk-updates-dev mailing list. But by only doing that, you are at the grace of the community to pick up your suggestion.
I would probably opt for the workaround in openHAB so it doesn’t take more than 2 months to get fixed.
6 Likes