Can you check the Chrome developer tools whether the browserserver really fired so many requests, especially the network tab is relevant, just check what requests are being fired at the server, most likely requests fail and are somehow retried and fail again, at least that is what I hope
under Linux: the refresh works perfectly - the complete data of the page is requested each time the refresh button is pressed.
Does it render graphs correctly or are there no (correct) graphs? Because the logging shows:
2017-10-09 11:02:00.113 [WARN ] [thome.ui.internal.chart.ChartServlet] - Illegal argument in chart: No Persistence service found.
2017-10-09 11:02:00.086 [WARN ] [thome.ui.internal.chart.ChartServlet] - Illegal argument in chart: No Persistence service found.
2017-10-09 11:02:00.073 [WARN ] [thome.ui.internal.chart.ChartServlet] - Illegal argument in chart: No Persistence service found.
Then I fear that you are demanding too much of the poor Pi’s every update of data item will lead to a refresh of chart, it seems that it just cannot keep up the pace. I see 18 requests in first second. And it only seems to be increasing, maybe you have to render / refresh your charts in a different way.
If you close the browser does it then normalize after some time? Will the connections be closed?
It is obviously linked to the usage of a windows browser like firefox or chrome. As long as I use a browser from a linux system it seems to be OK. When I start the view from Winwows, the number of hanging connections increases immediately due to the high number of requests from the windows browser:
Okay, that is great so the bug is mainly on the browser side. I fear that it is by design to refresh on updated items. I had similar but way smaller problems on my raspberry pi with my smart meter, I got so much data that it could not keep up anymore, but it did not come to this breaking point.
That is what I would suggest. I think the important part is to link to the prerendered chart so all the work goes on in the Grafana server and the browser has just the one request and one image to download each refresh period.
The problem does not occur because of the refresh period. The service breaks down as soon as I refresh manually the view inside Chrome / Firefox. As long as the browser performs the automatic reload nothing strange happens. Everything seems to work.
Things change because of manual interaction of the user.
Anyway - tomorrow I will check the proposed combination of DB an chart service on my raspberries.
This morning I tested the ‘too many client connections’ problem with a 64 bit Windows 8.1 pro. I was not able to reproduce it. The Pi3 serves faster than the PiZeroW (surprise surprise), but I got a response on every refresh browser view action.
Only the Windows 7 pro System causes the trouble with the connections.
jwiseman
(Mr. Wiseman (OH 4.2 Snapshot on Pi4))
45
I have a similar issue but I don’t have graphs. Running Synology OH2.3 stable with latest Java release; does this within 24 hours of a clean start (cache, tmp, logs) all cleared out.
2018-07-07 07:08:18.378 [ERROR] [me.storage.json.internal.JsonStorage] - Error writing JsonDB to /volume1/@appstore/openHAB/userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json. Cause /volume1/@appstore/openHAB/userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json (Too many open files)
Best, Jay
jwiseman
(Mr. Wiseman (OH 4.2 Snapshot on Pi4))
46
I found that I had exposed over 400+ items using the “openHAB Cloud” binding; once I removed all those exposed items - my issue went away.
I’m guessing there is a bug in having so many items exposed?