JSscripting: Error message "Java.lang.OutOfMemoryError: Java heap space"

@Oliver2
May be true that out problems have different root cause.
I don’t use the new script engine until now, even if would like to try the python one :slight_smile:
I also use the Java version which comes with openhabian.

I played more arround with my system and noticed that I can bring my OpenHAB easy in a crash during startup when I do thinks on the GUI or changing sitmap files in parallel.

Example error:

2022-01-03 15:51:26.250 [WARN ] [p.internal.http.HttpResponseListener] - Requesting 'http://feinstaubsensor-14255834/data.json' (method='GET', content='null') failed: null

2022-01-03 15:51:42.535 [WARN ] [e.jetty.util.thread.QueuedThreadPool] - 

java.lang.OutOfMemoryError: Java heap space

Than nealy 6minutes nothing (CPU load 388%!!) and:

2022-01-03 15:57:16.052 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.io.monitor.internal.EventLogger@d3c059' takes more than 5000ms.

2022-01-03 15:57:16.064 [WARN ] [org.eclipse.jetty.server.HttpChannel] - /chart

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.071 [WARN ] [e.jetty.util.thread.QueuedThreadPool] - 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.078 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.085 [INFO ] [org.eclipse.jetty.io.ManagedSelector] - Caught select() failure, trying to recover: java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.088 [ERROR] [se.californium.elements.UDPConnector] - Exception in network stage thread [UDP-Receiver-0.0.0.0/0.0.0.0:5683[0]]:

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.088 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.093 [WARN ] [work.deduplication.SweepDeduplicator] - Exception in Mark-and-Sweep algorithm

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.107 [ERROR] [org.apache.felix.fileinstall        ] - In main loop, we have serious trouble

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.107 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.107 [WARN ] [e.jetty.util.thread.QueuedThreadPool] - 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.110 [WARN ] [e.jetty.util.thread.QueuedThreadPool] - 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.112 [WARN ] [e.jetty.util.thread.QueuedThreadPool] - 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.107 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.110 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.114 [WARN ] [e.jetty.util.thread.QueuedThreadPool] - 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.114 [WARN ] [e.jetty.util.thread.QueuedThreadPool] - 

java.lang.OutOfMemoryError: Java heap space

2022-01-03 15:57:16.199 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = 543a2bc1-9ff9-4d70-a726-c4181728adfc, base URL = http://localhost:8080)

2022-01-03 15:57:16.057 [ERROR] [org.knowm.yank.Yank                 ] - Error in SQL query!!!

java.sql.SQLTransientConnectionException: yank-default - Connection is not available, request timed out after 374453ms.

	at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:555) ~[?:?]

	at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:188) ~[?:?]

	at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:147) ~[?:?]

	at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:83) ~[?:?]

	at org.apache.commons.dbutils.AbstractQueryRunner.prepareConnection(AbstractQueryRunner.java:204) ~[?:?]

	at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:287) ~[?:?]

	at org.knowm.yank.Yank.queryObjectArrays(Yank.java:578) ~[?:?]

	at org.knowm.yank.Yank.queryObjectArrays(Yank.java:560) ~[?:?]

	at org.openhab.persistence.jdbc.db.JdbcBaseDAO.doGetHistItemFilterQuery(JdbcBaseDAO.java:344) ~[?:?]

	at org.openhab.persistence.jdbc.internal.JdbcMapper.getHistItemFilterQuery(JdbcMapper.java:169) ~[?:?]

	at org.openhab.persistence.jdbc.internal.JdbcPersistenceService.query(JdbcPersistenceService.java:205) ~[?:?]

	at org.openhab.core.ui.internal.chart.defaultchartprovider.DefaultChartProvider.addItem(DefaultChartProvider.java:328) ~[bundleFile:?]

	at org.openhab.core.ui.internal.chart.defaultchartprovider.DefaultChartProvider.createChart(DefaultChartProvider.java:209) ~[bundleFile:?]

	at org.openhab.core.ui.internal.chart.ChartServlet.doGet(ChartServlet.java:320) ~[bundleFile:?]

	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) ~[bundleFile:3.1.0]

	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ~[bundleFile:3.1.0]

	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550) ~[bundleFile:9.4.43.v20210629]

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) ~[bundleFile:?]

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434) ~[bundleFile:9.4.43.v20210629]

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:294) ~[bundleFile:?]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.43.v20210629]

	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:82) ~[bundleFile:?]

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388) ~[bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:555) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:410) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:164) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:386) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [bundleFile:9.4.43.v20210629]

	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [bundleFile:9.4.43.v20210629]

	at java.lang.Thread.run(Thread.java:829) [?:?]

2022-01-03 15:57:16.335 [WARN ] [e.io.http.servlet.BaseOpenHABServlet] - Chart generation failed: null

==> /var/log/openhab/events.log <==

2022-01-03 15:57:16.365 [INFO ] [openhab.event.InboxRemovedEvent     ] - Discovery Result with UID 'shelly:shellyrgbw2-white:49e6bd' has been removed.

2022-01-03 15:57:17.827 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_CPUTemp' changed from 65.7 to 65.2

2022-01-03 15:57:17.835 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ReceiverOnline' changed from ON to OFF

2022-01-03 15:57:17.846 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'N_FS_VINDRIKTNING_RSSI' changed from 82 to 80

==> /var/log/openhab/openhab.log <==

2022-01-03 15:57:19.404 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 543a2bc1-9ff9-4d70-a726-c4181728adfc, base URL = http://localhost:8080)

After that my log look normal but the GUI was dead.

As a first step I increased my JAVA memory with the JAVA options.
In the past I had the experience that the default values are to low for my installation.
I hope no memory leak somewhere!!

With OpenHAB 3.2 I added also the Shelly binding, the Network binding and the Python scripting (which I did not try yet). May be its also connetected to that…

My installation is stable after I increased JAVA heap.

Could you please post the command incl. parameters you issued?

you find the EXTRA_JAVA_OPTS in file:

/etc/default/openhab

I have a 4GB PI4. So I don’t see why I should limit the memory so much as it is by default.
My values look now like this:

EXTRA_JAVA_OPTS="-Xms512m -Xmx800m -Dlog4j2.formatMsgNoLookups=true"

I made Xms and Xms just much bigger. I think default is “-Xms192m -Xmx320m”!?
System its much more responsive and stable now.

I increased them also in the past but with each (or some) updates the values are reset to default.

Excellent. Will try this, too.
Thank you very much

Good point I will try it by myself but do you think that the problem just delays or is OpenHab also cleaning the used memory?

I suppose each of you could try to find out.
Useful background info in this thread -

Good point I will try it by myself but do you think that the problem just delays or is OpenHab also cleaning the used memory?

Not OpenHAB it cleaning unused memory. The JAVA garbage collector is doing it. Just try it. I don’t want to say that it solves also your problem.

It will not solve the symptoms nor is it the root cause of the problem.
I‘d say it pushes the symptoms of the problem to a later point of time (which is to me a kind of solution):grinning:

The thing is you, the user, has to properly describe and identify the problem in the first place before you know where to properly address an information he thinks to be of value to.

The 3.2 release thread and even more so GitHub aren’t for problems as long as it is unclear what your problem really is about in terms of code, i.e. which component misbehaves.

The common understanding problem on this starts very early in the communication process:
Most what users consider to be a problem does not match those criteria.
I understand this can be frustrating to users because they are looking for help they do not get or to someone like you that wants to help but does not know where to turn to.
Then again, only when you identify a problem (in terms of code, not from the user’s point of view) and what component it is with, you will know where to address it, and you will also get the appropriate attention. The crux is about identifying problems without knowing enough of the inner workings of openHAB and that there’s noone to guide you through that.

Here for instance, when Java is spitting out of mem errors, this is NOT an OH problem because Java wants to use more mem than it is configured to use at most.
There might be a mem leak in OH as the underlying problem but as long as you have not properly identified that leak exists, it is not a problem in terms of code.
So for now you shouldn’t be asking for help on either of these channels because that might be annoying and hindering the volunteers over there.

Most of the time Java-out-of-mem is a user-caused problem because the limit depends on hardware, JVM, OS configuration, which are any user’s own responsibility to get right
openHABian defines a standard limit, too (right, you can set in EXTRA_JAVA_OPTS as mentioned above) and it’s not impossible that this default does not work for everybody.
But given the number and size of working installation with openHABian it is highly unlikely that you are the first user this is insufficient for.
So return to analysis and look for a mem leak instead.

Please pay attention to being helpful in the first place. You may not expect anyone to read your post to know the context of your system so comprehensively state it in the first place and keep repeating to state that whenever the information might be useful to an unknown or new-to-the party person that might want to help you.
Remember #1 from the post below: this is not a help desk, and there’s no ticket system.
There’s only this thread, and you should not spread information. Update post #1 of a thread when there’s relevant news.
Noone wants to waste his time digging through older posts just to get the current context right.

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

we can continue this discussion forever.
There are no problems with M5. After updating to Release build many users like myself had a problem. So it IS related to latest build.
If you read through my post, I am NOT requesting help.

I just wanted to bring this to a developer‘s attention where I think of it might be of interest. obviously it wasn‘t. No big deal. I was not complaining anything and I did not require further help or anything what you have detailed out in your post.

If I am complaining something then it is YOUR approach which I PERCEIVE as being offensive, and I want to point out just for escalation reasons, that I am not saying that your are offensive but I perceive it this way.
I have decided not to provide information about problems with OH anymore. This is just a reaction of how I perceive your activity. I hope that not more users will follow my example and I really hope that I am the only one who is perceiving it this way.

6 Likes

As long there is no evidence for a memory leak somewhere, it can solve it. At least in my case it looks now much better…

These types of problems are notoriously difficult to track down. I spent dozens of hours on one last year, and I’m a developer.

The best thing you can do as a non-developer is to show as simply as possible how to reproduce the issue. If a developer can’t make it happen themselves there’s almost no hope of tracking down the root cause.

There also are some very simple command line tools that can show memory and cpu utilization over time. I’ll try to share those shortly, but maybe not for a bit as I’m in the middle of moving into a new house.

2 Likes

Mark’s summed up the situation very well in his post above. If you can list the steps necessary to reliably recreate the error then it makes it easier (not easy but easier) for a developer to investigate. This needs to start from first principles, i.e. start with a basic OH install, then install JS Script, then create this rules file in this directory, then create this rule with this deliberate syntax error and save it, then watch the Java memory usage increase. That sort of thing.

I remember there was a Java memory leak in 1.6 or 1.8 that caused me problems for a long time. Sometimes Java ran out of memory a few hours after a reboot, sometimes a few days after a reboot. I worked around it by using the exec binding and a rule to restart openHAB every night at 1am. It didn’t solve the error but it prevented it from happening most of the time. (In the end someone discovered that leaving browser windows open at the PaperUI caused the issue so once I remembered to close browser tabs the issue didn’t reoccur.)

In summary, if you can explain how to recreate the error that would be excellent. In the mean time, it also might help you to use the exec binding to schedule a restart of openhab.

Hey Mark @mhilbush and Steve,
thank you very much for your moderate words.
Well, the problem can reproduced fairly easy. All is written from several users in the first half of this thread.
Furthermore there is a link to another post, where the same problem is described including a short description how to reproduce the problem.
(In short: create a faulty JS script and execute it a couple of times).

I have re-posted both links in the release thread AND I have created a bug issue where I described everything again.
I think that is enough for the moment. If you want to fix this problem then I am more than happy to contribute, test, etc. and do everything you need.
But I will NOT do in advance all the stuff stormi is requesting, as I am not asking for help.

Again, my intention is to raise hand and say, attention - there is a problem. If nobody cares that’s fine with me. If a developer requests support, I do whatever I can to help.

Just as a side note. Neither in this thread, nor in the other thread linked bove, nor in the release thread, nor on Github not a single developer, maintainer, whoever, took notice and was asking a single question.

My personal point of view is that we should start acting like a community. We, users, see problems, we report them, users who are able to fix these problems are requesting infos which we in return provide. That makes sense. That approach takes us, normal users, into the game of fixing problems.
That approach what is described above is at least to me, not feasible and irritating, so that I will refrain from posting new potential problems.

4 Likes

I totally agree. I also have the feeling that people who are using openhab with fun but may not have the same knowledge as the people who are involved in the development, are more and more pushed to leave this place. Very, very german rules here now!

A bit sad. And I don’t know if this is good for the project finally…

But anyway: Let us help each other as good as we can and see the positive sides…:slight_smile:

Still fun and thanks to all the developers who contribute to OpenHAB. Great work guys!!
I am sure most of them are happy with the users, who have fun with the SW everyday and give some feedback… Even if they are not following all the rules given in the forum…

1 Like

Well I am still with OH 2.5.12 and I have the heap space problems with the cpu up to 100% and than OH restart by itself.

ummm… Mark, who posted above is a developer. He actually is the guy who figured out a very similar problem with DSL rules when they had errors in them. Here is a link to that issue (about a year ago)

The thread T linked to in the second post in this thread has several developers involved.
Please understand, everyone here wants to help you and just because folks don’t post here in your thread doesn’t mean they aren’t reading this thread and following along.
There are a few members here who can be a little… ah… terse, but don’t judge the entire community based on a few (or even one) individuals. I also didn’t think it was necessary to split your post out of the release thread but it was a (perhaps overzealous) attempt to keep the thread focused.
I think I might have already asked you but if not, can you please put a link to your github issue in this thread? Have your included a ‘steps to reproduce’ in the issue as described by Steve two posts above yours?
As mentioned, these types of issues are difficult to debug.

1 Like

Since Oliver hasn’t replied I thought I’d have a look for it. I think it’s this one: [JS scripting engine] Memory Leak #11952

1 Like

I tried to fade out this thread…
But thanks.

which is correct. I added it to the other thread:

1 Like