openHAB 4 migration FAQ

MathiasVDA · July 30, 2023, 4:47pm

Great initiative!

I would suggest to also add this thread to the FAQ:

Michael_Paier · July 30, 2023, 5:49pm

Hi to All,

I’m also facing very high CPU loads. Before Upgrading to 4.0.1 I was running OH3.4.1 without any issues @ average CPU Load ~15-20%.

Running on, Raspberry PI 4, 8GB, Samsung 890 M.2 500GB

BTW: for OH4.0.1 I made a complete new Setup up on a new Harddrive, but I “configured” OH with a Backup.

wborn · July 30, 2023, 7:26pm

Can you change the display option in htop to show the thread names?
That makes it easier to figure out what is causing the load.

See:

Michael_Paier · July 30, 2023, 7:29pm

Hi,

I hope I made it as requested…

wborn · July 30, 2023, 7:40pm

It could be event handling related based on those thread names.

There have been a few PRs regarding event handling which may have caused performance issues:
#3141, #3299, #3523, #3533, #3702

Michael_Paier · July 30, 2023, 8:19pm

I was reading the PR’s, but reading does not mean understanding - thats too complex for my simple mind

Is there a way to check those EventTrigger-Issue for simple “end-users”?

Im running OH with 442 things, 1839 items, 322 rules (all in DSL)… I’ll have a horrible night, thinking of maybe checking everything or maybe updating a massive portion of my configuration…

laursen · July 30, 2023, 8:33pm

I also seem to have this issue now (with 4.0.1):

  PID USER      PR   NI   VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 5147 openhab   20   0  887048 581872   4768 R  98.7  58.5 102:08.36 upnp-main-queue

mstormi · August 8, 2023, 6:31am

5 posts were split to a new topic: Blockly issues after OH4 upgrade

mstormi · August 5, 2023, 4:29pm

6 posts were split to a new topic: Migration on Rocky Linux

pfroehlich · August 6, 2023, 4:00pm

Is it necessary to also remove the comment in the line

# initialconfig=/boot/initial.zip

in openhabian.conf?

Manni51 · August 7, 2023, 1:54pm

Yes, in openhabian.conf

laursen · August 7, 2023, 6:38pm

laursen:

I also seem to have this issue now (with 4.0.1):

  PID USER      PR   NI   VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 5147 openhab   20   0  887048 581872   4768 R  98.7  58.5 102:08.36 upnp-main-queue

Update: I haven’t seen this issue for some days, but moments ago it reappeared while I was stress testing the Hue binding.

openhab> threads | grep upnp-main-queue
"upnp-main-queue" Id=371383 in RUNNABLE
"pipe-grep upnp-main-queue" Id=374317 in RUNNABLE
openhab> threads 371383
Thread 371383 upnp-main-queue RUNNABLE
Stacktrace:
java.util.concurrent.LinkedTransferQueue.awaitMatch line: 652
java.util.concurrent.LinkedTransferQueue.xfer line: 616
java.util.concurrent.LinkedTransferQueue.poll line: 1294
org.jupnp.QueueingThreadPoolExecutor$1.run line: 194
java.lang.Thread.run line: 833

That line:

github.com

jupnp/jupnp/blob/4a3ab9dec37cb9be324d02f6dc81ffca74237e1e/bundles/org.jupnp/src/main/java/org/jupnp/QueueingThreadPoolExecutor.java#L194


      
          Thread thread = getThreadFactory().newThread(new Runnable() {
          
              @Override
              public void run() {
                  while (true) {
                      // check if some thread from the pool is idle
                      if (QueueingThreadPoolExecutor.this.getActiveCount() < QueueingThreadPoolExecutor.this
                              .getMaximumPoolSize()) {
                          try {
                              // keep waiting for max 2 seconds if further tasks are pushed to the queue
                              Runnable runnable = taskQueue.poll(2, TimeUnit.SECONDS);
                              if (runnable != null) {
                                  logger.debug("Executing queued task of thread pool '{}'.", threadPoolName);
                                  QueueingThreadPoolExecutor.super.execute(runnable);
                              } else {
                                  lock.writeLock().lock();
                                  try {
                                      if (taskQueue.isEmpty()) {
                                          queueThread = null;
                                          break;
                                      }

So after reading:

I’m now suspecting this is also caused by:

github.com/openjdk/jdk

8301341: LinkedTransferQueue does not respect timeout for poll()

openjdk:master ← DougLea:JDK-8301341

opened 06:52PM - 05 Jun 23 UTC

DougLea

+784 -1383

This update addresses performance issues across both LinkedTransferQueue and Syn…chronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue). Pasting from internal doc summary of changes: * * Class DualNode replaces Qnode, with fields and methods * that apply to any match-based dual data structure, and now * usable in other j.u.c classes. in particular, SynchronousQueue. * * Blocking control (in class DualNode) accommodates * VirtualThreads and (perhaps virtualized) uniprocessors. * * All fields of this class (LinkedTransferQueue) are * default-initializable (to null), allowing further extension * (in particular, SynchronousQueue.Transferer) * * Head and tail fields are lazily initialized rather than set * to a dummy node, while also reducing retries under heavy * contention and misorderings, and relaxing some accesses, * requiring accommodation in many places (as well as * adjustments in WhiteBox tests). --------- ### Progress - [x] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) - [x] Change must not contain extraneous whitespace - [x] Commit message must refer to an issue ### Issues * [JDK-8301341](https://bugs.openjdk.org/browse/JDK-8301341): LinkedTransferQueue does not respect timeout for poll() (**Bug** - P4) * [JDK-8300663](https://bugs.openjdk.org/browse/JDK-8300663): java/util/concurrent/SynchronousQueue/Fairness.java failed with "Error: fair=true i=0 j=1" (**Bug** - P3) * [JDK-8267502](https://bugs.openjdk.org/browse/JDK-8267502): JDK-8246677 caused 16x performance regression in SynchronousQueue (**Bug** - P3) ### Reviewers * [Alan Bateman](https://openjdk.org/census#alanb) (@AlanBateman - **Reviewer**) ⚠️ Review applies to [eec7e491](https://git.openjdk.org/jdk/pull/14317/files/eec7e4915a70d4b8803374794f37abeeeb2e7360) ### Reviewing <details><summary>Using <code>git</code></summary> Checkout this PR locally: \ `$ git fetch https://git.openjdk.org/jdk.git pull/14317/head:pull/14317` \ `$ git checkout pull/14317` Update a local copy of the PR: \ `$ git checkout pull/14317` \ `$ git pull https://git.openjdk.org/jdk.git pull/14317/head` </details> <details><summary>Using Skara CLI tools</summary> Checkout this PR locally: \ `$ git pr checkout 14317` View PR using the GUI difftool: \ `$ git pr show -t 14317` </details> <details><summary>Using diff file</summary> Download this PR as a diff file: \ <a href="https://git.openjdk.org/jdk/pull/14317.diff">https://git.openjdk.org/jdk/pull/14317.diff</a> </details> ### Webrev [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/14317#issuecomment-1577305984)

This would mean it’s a bug in openjdk 17, not in openHAB, and there’s nothing we can easily do about it.

laursen · August 7, 2023, 6:46pm

You gotta be kidding me, now:

top:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
11216 openhab   20   0 1318172 472096   4528 S 256.2  47.4   4740:45 java

top -H -p 11216:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
25409 openhab   20   0 1318172 471856   4528 R  99.7  47.4  93:36.83 upnp-main-queue
30546 openhab   20   0 1318172 471856   4528 R  99.7  47.4  15:19.09 safeCall-queue

Hit by both cases.

mstormi · August 8, 2023, 6:20am

3 posts were split to a new topic: JS issues after OH4 upgrade

mstormi · August 8, 2023, 6:30am

Dear community members, please respect forum policy / posting rules.
Stay on topic and stay tight. The topic is FAQ here.
For anything not strictly related and of relevance to the FAQ, open your own threads.
Same if you want to discuss any of the FA questions in more detail.
When you do in wide-ranged or overview-like threads like this one, it’s quickly becoming an unreadable mess.
Thank you.

How to ask a good question / Help Us Help You - Tutorials & Examples - openHAB Community

wborn · August 18, 2023, 3:47pm

You might also want to add to the FAQ that old and incompatible OH 3.x .jar/.kar files in the /addons dir (or installed via the Marketplace) should be removed/updated. They can cause a lot of issues as observed in: Endless loop during start of OH4.0.2 service after upgrade from OH4.0.1

rlkoshak · August 18, 2023, 4:04pm

I wonder if this should be done by the upgrade processes in the various installation methods. They can move them to a different folder perhaps (they should not delete them). And of course they should log out that it’s moved them.

Because it causes such a significant problem, and the end user is going to have to do something to manually download and install the newer version anyway, I don’t see that much of a down side. Shall I open an issue or is there something obvious here I’m not seeing that makes it a bad idea?

wborn · August 18, 2023, 4:29pm

Yes I agree that this should be handled better so I welcome the issue.

rlkoshak · August 18, 2023, 4:37pm

github.com/openhab/openhab-distro

Clean up addons folder on upgrade

opened 04:37PM - 18 Aug 23 UTC

rkoshak

Leaving old .kar and .jar files in the addons folder after an upgrade can lead t…o significant problems (see https://community.openhab.org/t/endless-loop-during-start-of-oh4-0-2-service-after-upgrade-from-oh4-0-1/148774). I recommend that the installation scripts should look for and at a minimum move those files somewhere else as part of an upgrade, with logs of course. It gets tricky with snapshots I think because moving from one snapshot to the next within the same overall version of OH doesn't necessarily invalidate the stuff in the addons folder. But I think having OH come up in an infinite loop because the files are there is event worse.

mstormi · October 13, 2023, 7:12am

2 posts were split to a new topic: Upgrade questions