I had version 2.5.4 running for a while, and started having out of memory errors. I happened to notice all the bindings were version 2.5.5–what would do that? How can I get them all back to 2.5.4 to see if that fixes this problem? My bindings were originally all installed with paper UI (I think it was this release that I did use the console to get a newer version of one binding).
You installed a new binding or cleared cache. That installed the latest 2.5 version, which is 2.5.5.
If you are using anazonechocontrol, that is the source of your memory issues. It started last Friday due to a change on Amazon’s servers. The issue has been fixed in latest snapshot. Search the forum for a download link.
1 Like
I was wondering about that binding. I also noticed this a lot, but it started May 6, so didn’t think it was related:
2020-06-13 00:31:48.929 [INFO ] [control.internal.WebSocketConnection] - Web Socket error
java.nio.channels.AsynchronousCloseException: null
at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.close(HttpConnectionOverHTTP.java:181) ~[?:?]
at java.util.ArrayList.forEach(ArrayList.java:1257) [?:1.8.0_232]
at org.eclipse.jetty.client.AbstractConnectionPool.close(AbstractConnectionPool.java:208) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.DuplexConnectionPool.close(DuplexConnectionPool.java:237) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.HttpDestination.close(HttpDestination.java:385) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.HttpClient.doStop(HttpClient.java:260) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:93) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:180) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:201) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.websocket.client.WebSocketClient.doStop(WebSocketClient.java:371) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:93) [bundleFile:9.4.20.v20190813]
at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection.close(WebSocketConnection.java:159) [bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection$2.run(WebSocketConnection.java:184) [bundleFile:?]
at java.util.TimerThread.mainLoop(Timer.java:555) [?:1.8.0_232]
at java.util.TimerThread.run(Timer.java:505) [?:1.8.0_232]
Didn’t think to search for that one before. Thanks much.
With the fixed binding the memory link problem and the above web socket errors are gone. And another thing. When I first had the out of memory on Saturday and looked at the logs, there were also some errors in the rules. Not sure how I missed those or it the file got accidentally changed, but after fixing those started getting a case:
2020-06-14 09:36:56.654 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Vacation_Mode': The name 'Vacation_Mode' cannot be resolved to an item or type; line 34, column 6, length 13
The odd thing, the item exists, definitely didn’t have the case wrong or anything. A grep with that name shows several usages in the rule, but the one line was giving the above error. But that’s gone now too with the binding update. Weird.
Thanks for the fix.
That’s a known and not fully understood issue that is expected to disappear with the change to the new rule engine in openHAB 3. If you use the new rule engine ans JSR223 scripting in OH2.5, you’ll probably not have that problem, too.