[OH-httpClient-common] binding hangs on Waiting (OH run by processor with 10 cores) #13689
Comments
jeremias-jordan
added
the
bug
|
I don't think that this is a bug in the binding. It looks like there are some port mappings missing in your Docker configuration. The binding listens on several ports and is wating for events from the CCU. See the binding's documentation for the list of ports. BTW: The forum is much better place if you are looking for help with problems like this. There are several users of the Homematic binding within a docker container and there are several thread in the forum. |
|
But as long as i understand the docker configuration correctly, there should be no port mappings necessary because i've used the host network instead of a bridge so the container should have access to all ports on the host system. That's also the official recommendation on docker hub. I also checked on the host system if any of the ports are blocked by the firewall or other processes and there were no issues. I've also searched in forums and at least with older versions, this configuration should technically work. If i have overlooked anything obvious, i would be thankful for hints where to start debugging this issue. Anyway, sorry if this isn't a bug. I'll post my issue in openhab forums. |
|
Update: The Problem was in the ThreadPool of jetty. This was an additional part of my openhab.log; Got the solution from here: https://community.openhab.org/t/fix-for-jetty-error-when-running-on-host-with-many-cores/57449/7 I just added these lines to the runtime.cfg: Honestly, still seems like a bug to me or is it intended to change the ThreadPooling manually as end user? |
You are probably in a very unusual setup if so many threads are required for HTTP requests in OH. I guess the default settings are OK for 99% of users. We cannot set the pool too much high by default as most of users are using small machines with limited resources like RPI. So I believe only users with a very unusual setup should have to change these settings. |
|
@lolodomo i guess the only way my setup could be unusual is the hardware itself, i have a server with a Xenon E5-2650L v2 processor with 10 Cores. Besides that, the setup is pretty common. Does a CPU with many Cores pump up the required thread count? Or which instance is responsible for calculating the required threads? Currently i have the MQTT and modbus Binding installed. But as i wrote in Steps to Reproduce the issue occurred even on a fresh install of everything with nothing but the homematic binding installed. Other Bindings did work well. |
I am not enough expert to answer to that question but looks like a good question. |
|
... but @mhilbush was mentioning a problem with many cores in that issue: |
|
@lolodomo Thanks, seems to really be an hardware issue then and probably not relevant for most users on small machines. However on a more powerful server the thread management seems to be badly implemented. I don't think it's that efficient to have 45 (idle) threads just to deal with http on one openhab binding. Unfortunately i'm also not an expert and i still don't understand how the required Threads are calculated even after reading the issue you mentioned and parts of the source code. It would be great if someone, who understands it could just set a fixed limit for Thread creation so that there aren't that many threads running on idle. |
|
Maybe @mhilbush can explain the link between the required threads and the number of cores? |
lolodomo
changed the title
|
In my opinion this issue is not Homematic specific. I think similar problems can happen with other binding, too. Can you change the subject? |
jeremias-jordan
changed the title
|
@J-N-K i think this should be moved to core as these webclient thread count is not something that is controlled by the addons repo is it? |
|
@jeremias-jordan are you able to confirm this still exists on openHAB 4.2.x ? As many changes (java17, jetty version and others) have been merged it might already be fixed. I also remember something about spawning threads on demand has changed. but can't remember the details anymore. If the solution is to change the runtime config, this issue should be transferred to the distro repostitory |
Expected Behavior
Should be possible to add things to binding, Binding should start up correctly on OpenHab Startup
Current Behavior
No matter which installation method i choose, the bundle hangs on "waiting" in the console
I tried restarting, uninstalling and reinstalling, different installations methods (UI, console), cleaning the cache, basically everything i can do (even a complete reinstall of docker and openhab) but nothing helped. Here is a log excerpt after setting the log level to TRACE. Most of it keeps repeating, i hope i have included the important parts.
And here is the bundle:diag
Furthermore there are some issues with the UI. For example i can't add things to the binding, if i do it manually, it stays on Uninitialized.
Steps to Reproduce (for Bugs)
cd /opt/openhab mkdir conf addons userdata chown -R openhab:openhab conf addons userdataCopy the following docker-compose file to /opt/openhab
then
and install the Homematic Binding via UI, console (with feature:install) addons.cfg, etc.
My Environment
The text was updated successfully, but these errors were encountered: