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.
Wanting to report right at 24 hrs. running the patch and CPU % has not gone above 2 - 3 % the whole time even with all my Jruby rules enabled. For perspective, that would not happen, even with most (all) my Jruby rules disabled, every morning when I would wake up and every evening when I’d get home from work, I’d hear the fan running and TOP would show the java thread at 100% CPU (or over)
Not only that… but as Oli says above, the computer seems much more responsive. Overall performance seems much improved!
BRAVO BRAVO
Thank you all, especially Wouter, awesome job
I however run on Windows (yes, I know…). There are so few of us around.
Would these changes make any difference to a Windows system? I would like to try them as well - but only if there is a chance they improve the situation on Windows (most of the comments have been pi and Linux)
Thank you Wouter!
Installed your fix yesterday evening and finally the annoying safecall-queue issue is gone. I am on OH 4.0.1. Thanks again for the fix and the clear installation instructions!
Over 72 hours I’ve had one little incident where the java thread in top had my cpu hitting 100%. Running the script Cody wrote cleared the problem so it obviously is still the safeCall queue issue but… big caveat… I disabled all my Jruby rules and was still having the problem. After installing the patch I (recklessly) re-enable all my Jruby rules. Most all of them had some issues. I figured out how to fix them (or at least a work around) and things have been quiet since. CPU never gets over 2 or 3 percent.
What follows is my humble opinion. I am an amateur programmer (hack) but never learned java, so I can’t help figure this out. But in my opinion, a buggy rules should not cripple openHAB. The bug in my rules I’m almost sure is a bug in Jruby was my own fault for misconfiguring Ruby (same link as above) and shame on me for blaming this issue on my poor rule writing skills and I’m happy it finally got looked into but again… should a buggy rule cripple openHAB? Just my opinion. Still huge gratitude for the fix, you gave me my beloved openHAB back after I almost threw my hands up and uninstalled it. I installed OH4 in April and Jruby rules that had run for months in OH3 started throwing errors. (again, new Jruby library, shame on me)
I get high CPU an then it seems to be unstable. Openhab tried to fetch http data and try also to update items, but that get stopped after a while. CPU was 100%. After I installed the small fix, its look better now. But is Openhab rebooting itself if there is a timeout?
I have open a thread about unstable issues here: Openhab 4.0.1 unstable - #7 by Wikibear
At the moment I do more documentation.
The interesting part is what really happen and what try to do everything that Openhab get unstable and produce this timeout.
I have tested on my equipment, a miniPC with Windows 10 that have this issue… it seems that worked… let me test a little more time, but I think CPU usage is now ok.
Actually, sorry to report but twice in the last 24 hrs (after days of < 3% cpu ) I’ve found top pinned at over 100% by the java thread, can’t believe it, so just upgraded to 4.0.2
I think this is something unique to my install since others aren’t reporting
Stupid question for Wouter… the fix doesn’t have to be uninstalled once upgraded to 4.0.2 right?
