On Wed, 6 Jul 2022 05:59:21 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> xpbob has updated the pull request incrementally with one additional commit >> since the last revision: >> >> update header > > It's not clear that introducing this as a standard API is the right thing to > do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", > "CPU period", "soft limit" etc. will last the test of time and that we don't > be back here next year with another PR to deprecate or replace this API? I > don't disagree that exposing a MXBean could be useful for > monitoring/management purposes but I think we have to be cautious getting > getting locked in. A possible starting point for prototyping purposes and > getting feedback is a JDK-specific MXBean (module jdk.management). > @AlanBateman @jerboaa That's a good idea.Adding a special bean is only > available on Linux systems.I do not know the process of creating a CSR, can > you help me create a CSR It's too early to think about a CSR, probably a bit premature to create a PR too because it will take a few iterations to come to agreement on what API to expose, if any. I don't think this should be a standard API, meaning java.management/java.lang.management.ContainerMXBean is not the right place for this. A JDK-specific MXBean is an option but it would only be usable on Linux and maybe only usable when running in a container environment. Working down, it's not clear to me how stable the attributes are and the mapping to both cgroup v1 and v2. There is also overlap with OperatingSystemMXBean which already defines the "TotalSwapSpaceSize" attribute. There's another level of detail beyond that with unusual value -2 to distinguish "not available" from "not supported". So I think there are a few things to think about there. Another direction to think about is not exposing an API that you can compile against but instead just register a MBean that provides access to the attributes that are interesting for the container environment. By this I mean ManagementFactory.getPlatformMBeanServer().registerMBean(...). This would be enough to browse the MBean and its attributes in any JMX console and may give you a bit more flexibility to expose attributes that are specific to the cgroup version. I'm not saying this is the right direction, I'm just listing here is something that you could be explored. If the main use case is JMX consoles rather than programmatic access then it may not be too bad. ------------- PR: https://git.openjdk.org/jdk/pull/9372
