laursen
(Jacob Laursen)
August 7, 2023, 6:38pm
30
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:
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:
Platform information:
Hardware: Intel NUC. Intel(R) Coreā¢ i5-8259U CPU @ 2.30GHz, 16 GB RAM
OS: Linux 5.15.0-58-generic #64-Ubuntu SMP x86_64 Ubuntu 22.04.1 LTS
Java Runtime Environment: OpenJDK 64-Bit Server VM (build 17.0.5+8-Ubuntu-2ubuntu122.04, mixed mode, sharing)
openHAB version:3.4.1
Iāve noticed that my openHAB is often above 100% CPU usage. Iāve got a lot going on, so havenāt been excessively concerned. But then I ran the following to figure out if itās any particular thread thatāā¦
Iām now suspecting this is also caused by:
openjdk:master
ā DougLea:JDK-8301341
opened 06:52PM - 05 Jun 23 UTC
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
(Jacob Laursen)
August 7, 2023, 6:46pm
31
laursen:
This would mean itās a bug in openjdk 17 , not in openHAB, and thereās nothing we can easily do about it.
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
(Markus Storm)
Split this topic
August 8, 2023, 6:20am
32
3 posts were split to a new topic: JS issues after OH4 upgrade
mstormi
(Markus Storm)
August 8, 2023, 6:30am
33
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
1 Like
wborn
(Wouter Born)
August 18, 2023, 3:47pm
34
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
1 Like
rlkoshak
(Rich Koshak)
August 18, 2023, 4:04pm
35
wborn:
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.
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?
1 Like
wborn
(Wouter Born)
August 18, 2023, 4:29pm
36
Yes I agree that this should be handled better so I welcome the issue.
mstormi
(Markus Storm)
Split this topic
October 13, 2023, 7:12am
38
2 posts were split to a new topic: Upgrade questions