Yes, I think so.
EDIT:
Now it works. First I have to write the command “bundle:list” and then “bundle:list | grep -i amazon”.
Strange. However, now I will try the solution from Jan.
EDIT2:
The Web socket error still appears in the log 
As stated above from our helpful guys, the log entry is still generated because the problem is still there. What Jan could do is stopping the binding to generate the OutOfMemory (OOM) situation, which requires to restart openhab or the complete system (and might even give you some more headache when running on a raspi).
So the only thing to do ATM is to disable the binding or to live with the logentry (and possibly to miss some functionality) until someone is able to to find out what has been changed on the amzaon side and adjusts the binding code.
Stay patient.
2 Likes
…ah you just beat me to pretty much exactly the same reply 
Yes, this post is only 3 days old… so patience until it’s worked out! Although running:
free -h
on Rpi still shows RAM reducing even after applying the workaround. Could possibly be something else though
i think you have to login in the karaf console at first (openhab-cli console, then the pw) and after bundle list install the fix…
that works for me, the memory leak is gone, the error message is not into my focus…
thanks nephrotranz, Flip and J-N-K
If you type anything in Linux case sensitive is important. After Info setting or debug restart Binding to take effect…
Hi,
i have the web Socket error to in OPENHAB 2.5.5-1 disused in
Java heap space…java.lang.OutOfMemoryError
and
Web Socket error {}
now i was pointed to this post. (I closed the other ones pointing them to this posed to bring everything together!)
The error is still there!
See:
2020-06-15 14:06:04.943 [INFO ] [nternal.WebSocketConnection$Listener] - 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_252]
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:171) [bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection$2.run(WebSocketConnection.java:200) [bundleFile:?]
at java.util.TimerThread.mainLoop(Timer.java:555) [?:1.8.0_252]
at java.util.TimerThread.run(Timer.java:505) [?:1.8.0_252]
The new jar-file did not help!
And there is a new quality in town: after a periode of time: Openhab crashes with another warning:
2020-06-12 22:56:28.026 [WARN ] [org.eclipse.jetty.server.HttpChannel] - /start/index
java.lang.OutOfMemoryError: Java heap space
2020-06-12 22:56:38.624 [WARN ] [org.eclipse.jetty.server.HttpChannel] - /start/index
java.lang.OutOfMemoryError: Java heap space
So there is a new qualitiy in town!! System crash!!!
Please have a look and help!
Thanks
Cheers
Stef
The OOM is from 2020-06-12, so this is clearly from the release version. This is fixed with the version above and will not happen anymore.
As I said before: the bundle above is NOT fixing the root issue (websocket connection fails) but ONLY fixing the erroneous closing of a failed connection which lead to the OOM.
1 Like
Fine to hear,
but error is again still there… maybe someone which has build the fix last time have a look to.!!!
And should know that there is a major issue!!
An now - read carefully - there is an other quality in town: SYSTEM CRASH
…
Thank you
and btw: pleas explain OOM it´s helpfull for everybody to know what you are talking about
Cheers and Thanks
Stef
Maybe you should read my post more closely. The system crash is due to the OOM-exception (your log from 2020-06-12). This is fixed above. The connection error is still there and needs to be fixed independently.
Edit: OOM = Out-Of-Memory.
And it was a hint in Java heap space…java.lang.OutOfMemoryError from CM6.5 H102Regular which i followed to fix…
…
…
Cheers
Stef
1 Like
Hi Stef,
there are a lot of dots and exclamation marks in your post but this doesn’t make it faster or more productive to find a fix for the issue. Please keep in mind that we all do our best to remove all of the issues. If there is still a memory leak in the version @J-N-K provided -i don’t think so- more people will report it. If you scared about “the other quality in town: SYSTEM CRASH” you can disable the binding until it is fully fixed. Thanks for being patient and for your feedback in any way.
2 Likes
Unfortunately not. It would be nice to see the full configuration of those that DO NOT experience problems. Maybe something is sent along which prevents the unsuccessful connect but since I neither use the binding nor own a supported device it‘s not so easy to debug.
After the hint of @summerguy i checked the ioBroker Project and it seems they also have a problem with Amazon login depending on the cookies. They wrote that the reason is a little change in the HTTP-Headers, but not what changed. Maybe this is the same issue -i don’t know at the moment- but i still check the headers and the cookies. There is no push on the ioBroker project because they want to test the changes. It is possible to reproduce this “endless web socket loading” in the browser. If i re-send the web socket request it never returns a response, so the same for the binding. This is what i got at the moment.
As i understood there is no one which do not experience problems. Only people who do not experience memory problems with the current release version, but it seems they all have web socket problems.
2 Likes
As i stated before: I DO experience the problems. So no help from “the other side”, sorry.
Anyway: if any sort of logs might be helpful: let me know. I’ll take the time and try to generate what is needed.