Provide fallback bean for OS info (fixes #502)#503
Conversation
When run in a container, the getOperatingSystemMXBean can throw an exception (see #502 for a full trace where a cgroup is not properly mounted inside the container). This fix provides a fallback object that provides the basic information about the OS for such cases.
|
Looks good in general, we might need to look into Spark and maybe disable it's management console which apparently cannot handle the problem as well. It's interesting that both older and newer JDKs don't have the problem. |
|
It seems this was resolved in backport 17.0.8-oracle. But we build our Docker images against the implementations from https://jdk.java.net/ where we have only 17.0.2. |
Could we use https://github.com/adoptium/temurin17-binaries/releases/tag/jdk-17.0.9+9 ? |
|
@lbulej I have created renaissance-benchmarks/docker-buildenv#35 that adds Temurin releases. Maybe we should use these in general instead of the reference implementations from https://jdk.java.net? Seems they are getting more backport fixes. |
I'm fine with that. BTW, assuming that helps, do you think we still need the fallback MX bean (given that if the underlying framework uses JMX too and does not handle it, a NPE from the depths below will still bite us)? |
I think that it might bite us in the future and it at least makes it runnable for some benchmarks. I do not think it brings a huge overhead and the fallback is pretty self-contained. But the decision is up to you, I guess. Anyway, I will try to create a new PR switching to the Temurin releases soon. |
2 participants
When run in a container, the
getOperatingSystemMXBeancan throw an exception (see #502 for a full trace where a cgroup is not properly mounted inside the container).This fix provides a fallback object that provides the basic information about the OS for such cases.