Thanks for your suggestion to allocate more memory for the JVM. However, the OOM Exception only occurred on the very first attempt for me, it runs “fine” with the defaults of -Xms512m and -Xmx2g.
And with “fine” I mean that it runs but it takes 10-12mins to even start, everytime I click the “Run OSGi” button.
It keeps resolving for 10-12mins (possibly runs into a timeout then) and then the runtime finally starts and the CPU usage goes back to almost idle.
Adding more memory doesnt change anything on those 10-12mins, it just uses more memory, thats all
@wborn Could you please install a second version next to yours with a separate bundle pool to see if you run into my issue as well?
I created a fresh Ubuntu 21.04 VM with only 8GB of memory to simulate a more common PC. Then I also ran into your memory issues when launching the app. The reason is that there is no -Xmx VM parameter specified so then the JVM assigns x% of your total memory to the Java application. On my real PC that was 16GB while in the VM it was only 2GB.
According to VisualVM it takes a lot of memory to initially resolve/start all bundles. But after that it drops significantly:
It will probably work for you as well if you add -Xmx8g in the JVM Arguments, that will add -runvm: -Xmx8g to the app.bndrun file. Maybe we can find a way to reduce this big amount of memory needed.
Thank you very much for your analysis. I think this is going into the right direction.
However, I am now at -Xmx10g and it uses that much memory, but it still takes 1.5mins so 90 seconds until the runtime starts…
Tested with bndtools 5.3 on latest 202103 Eclipse with zulu java-11.
So giving more ram to the app.bndrun startscrip certainly improves the situation, i.e. from 12mins down to 1.5, but still thats A LOT…
The runtime used to start within seconds, roughly anything below 10, I would say…
Edit: I am also wondering why bndtools needs to resolve on EVERY startup… I would think that clicking the “Resolve” button and saving the app.bndrun file would be sufficient for the next run, as everything is already resolved at that point.
Edit2: I found https://issues.apache.org/jira/browse/KARAF-6068 which looks as if this might be related. I don’t know if we have such a situation where a bundle exports packages of different versions though…
You can also try it on the current main branch by removing all runbundles and reresolving them. Then move the pax-logging bundles to the top so they immediately apply the right loglevels.
it looks like ti very much depends on which addons/bindings you add to the run configuration. The default was fine for me, but when I added the tr064 binding I face the out of memory error:
This seems to be eclipse installer related. I made a copy of my folders (.m2, .p2, openhab-main) from my former computer to the new one and everything seems to run normally.
I am now having the same issue.
It started on my existing 2022-03 IDE setup, so I tried a fresh 2023-03 IDE install, but it is the same issue there. @triller-telekom I do not even have added a single add-on, so that does not seem the cause for me.
I also tried rearranging the runbundles order, but no luck.
If anybody has a good hint how to resolve this issue, I’d be very thankful.
Hi, no solution but I like to tell anyway.
I have had an IDE setup as 2022-12 used since a week back, this had have Resolve mode as manual and non Resolve has been done, and everything works as usual.
I then yesterday did an manual Resolve and the result is as below. I did Run OSGi at 23:20, and then went to bed.
This is what I found this morning:
Exception in thread “pool-1-thread-1” java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1663)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
at java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1070)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1589)
Welcome to Apache Felix Gogo
g! 00:04:38.328 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 4.0.0 (build Unknown Build No.)…
Main Gui works as usual.
Best Regards Basse
It is and it isn’t - resolver is there to compute dependency graph between packages and thus bundles which needs to be started. Not only Equinox Resolver but also Felix Resolver are known for running into troubles under certain conditions. Since package graph is usually fairly large, especially if you run entire openhab, depending on depth of the graph query you might get almost infinite number of permutations. Interestingly enough both resolver implementations avoid running into stack overflow errors.
If you look for a solution I have two suggestions:
Try disabling and enabling specific bundles in a hope to find a root cause, note it might be two or more bundles which contribute to problem by making clash or diverge of transient dependencies.
Plug a debugger into resolver and find where it begins to get into infinite cycle, then look which packages are causing it. Simple solution will be avoiding them, but a permanent solution of this problem will be patch which will solve an algorithmic puzzle in resolver logic.
Well, I was more referring to the number and state of these threads. Debugging or even doing this by trial-and-error is finding a needle in a hay stack.
The short-term solution is to move away from Eclipse and go with VS Code which is using the regular distribution with Karaf. Unless some is volunteering to craft an Eclipse setup that allows one to swiftly debug against a separately running JVM
Not really. I now avoid hitting “resolve” myself. The checked in launch config works for me, so I manually add stuff that I need without automatic resolution.
when IDE was initialized I did an update dependencies, run debug → ok
Maven->Update project
update dependencies, run debug → ok
then changed the branch
added manually a jetty dependency and my binding
update depencies, run → ok
The only thing, which remains (was also before): Every time I save code (and auto build is enabled) I get the following message:
Error executing jar goal: Failed to execute mojo org.apache.maven.plugins:maven-jar-plugin:3.0.2:jar {execution: default-jar}
Failed to execute mojo org.apache.maven.plugins:maven-jar-plugin:3.0.2:jar {execution: default-jar}
You have to use a classifier to attach supplemental artifacts to the project instead of replacing them.
:
