[GR-40463] Add experimental support for remote management over JMX to Native Image

[roberttoyonaga]

TL;DR

Currently connections via JMX are not supported in native images. This work is to add initial support for that.

Goals

Achieve similar functionality as in OpenJDK where remote management of managed beans is possible. JMX support will be optionally added at image build time through --enable-montioring=jmxclient,jmxserver options.

Details

Building a JMX server or client should be possible. Connection should work with authentication as well as SSL. When a JMX server is built and run with remote JMX options, the server should start up right away at runtime similar to in OpenJDK. Configuration will be done in separate client and server features for modularity.

[christianhaeubl]

FYI @fniephaus, @christianwimmer, @vjovanov

[fniephaus]

Thanks for volunteering to work on this, @roberttoyonaga! Let us know if you need any help from our side.

[roberttoyonaga]

The Javadoc here says that the MBeanServer should be initialized at runtime. Is the intent here that the user, in their application code, manually initializes it by calling ManagementFactory.getPlatformMBeanServer()? Would it be better if the MBeanServer and JMXConnectorServer were started automatically if a flag was set at native image build time (similar to openjdk)? Maybe this could be achieved using a jdk.RuntimeSupport.Hook startup-hook.

[christianhaeubl]

Yes, the MBeanServer is currently initialized lazily, when ManagementFactory.getPlatformMBeanServer() is called for the first time. For the JMXConnectorServer, I don't think that we have this possibility because we need to actively listen for incoming connections. So I suppose we will need something like a startup hook to trigger the initialization.

How does the JMXConnectorServer get initialized on HotSpot? Is there already some JDK infrastructure that we could reuse?

[roberttoyonaga]

It looks like jdk.internal.agent.Agent initializes the JMXConnecterServer. It also initializes the MBeanServer by calling ManagementFactory.getPlatformMBeanServer(). Hotspot calls on this class to do all the initialization if JMX is specified at runtime.

Maybe I can reuse this class in a start up hook in the ManagementFeature to automatically initialize JMX services at runtime if the user specifies they want JMX functionality.

[roberttoyonaga]

After some basic experimenting, it seems like reusing the JDK infrastructure is possible. And it is also possible to do the MBeanServer and JMXConnecterServer initialization at runtime with a start-up hook so that a client is able to connect. However, reusing the JDK infrastructure requires configuration for things like reflection, serialization, proxy classes, and resource bundles to be specified at image build time. Currently, I have everything specified in json files created by running the native image tracing agent. This means that anyone wanting to use JMX would need the proper configuration at image build time. Is this an acceptable solution? Could there be a better way?

[fniephaus]

Cool, that's good news! For JDK code, we do use internal features instead of JSON config files. An example is the JDKInitializationFeature, but we also have more specific ones such as JNIRegistrationAwt.

How large are those config files? Could you maybe turn them into something like a JMXInitializationFeature? What do you suggest, @christianhaeubl?

[roberttoyonaga]

Thanks Fabio! Yes I can give that a try. The reflection json file is about 600 lines (so maybe ~200 classes), but all the other config files are pretty small (<50 entries).

[roberttoyonaga]

Doing all the configuration inside of a feature is working well. I am thinking of splitting the configuration for the client and server into 2 separate Feature classes. What do you think of this idea?

Do we still need a separate ManagementFeature or can this code be merged with the JMX server configuration feature code?

I am running into a runtime linking error with native JNI method jdk.internal.agent.FileSystemImpl.isAccessUserOnly0(String) I have tried adding the library with NativeLibraries.addStaticJniLibrary(String, String ...) and registering the class for JNI access with JNIRuntimeAccess but the liking error persists. Do you know how I might resolve this?

[fniephaus]

Splitting the config into server and client features sounds reasonable. If you think it can be merged with the ManagementFeature, please go ahead. This is something we can still discuss during code review.

I'm not sure what the error is about. Maybe @christianhaeubl has an idea? Probably best you open a PR with your changes so that we can reproduce this and start commenting on the implementation.

[roberttoyonaga]

Ok I have created a draft PR here: #4786
I added some comments to explain the current state of the work.