openHAB 4 migration FAQ

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.