NotCompliantMBeanException during cache creation

[Gunnar Morling]

Hey all,

Sorry for the late reply, I was travelling for a conference last week.
Indeed I had the following as part of my Java invocation, as you suspected,
Alan:

    -Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

It happens automatically from within Kafka's launch scripts, which is why I
hadn't noticed it at first. Once I dropped that part, I could create the
AOT cache file successfully. Interestingly, the error still occurred when I
replaced the above with the following:

    -Dcom.sun.management.jmxremote=false

I'd have assumed this not to be the case? Similarly, I tried to specify
-XX:+UnlockDiagnosticVMOptions -XX:+AllowArchivingWithJavaAgent to allow
the cache creation with an agent, but to no avail. The only way it did work
was by removing the three -Dcom.sun.management.* options altogether.

I don't fully understand all the moving parts here yet, but it appears as
if the ergonomics of this feature could still be improved? In any case,
thanks a lot for your help, I was able to create the AOT cache file in the
end and it shaved off a nice chunk of the Kafka start-up time!

Best,

--Gunnar



On Tue, 18 Mar 2025 at 05:40, <ioi.lam at oracle.com> wrote:

>
> On 3/16/25 1:09 AM, Alan Bateman wrote:
> > On 16/03/2025 02:12, ioi.lam at oracle.com wrote:
> >> Could you send the exact command-line that causes the error? If you
> >> can share a self-contain reproducible test case, that would be great!
> >>
> >> Looking from the stack trace:
> >>
> >>     at
> >>
> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:542)
> >>     at
> >>
> jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:316)
> >>     at
> >> jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:448)
> >>     at
> >> jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:601)
> >>
> >> It looks like you might have specified a Java agent in the "java
> >> -XX:AOTMode=create ...." command line. Can you try removing that and
> >> see if it works?
> >
> > I assume it's something started with -Dcom.sun.management=... to start
> > the JMX agent. This sets in motion the registration of management
> > beans and the JMX introspector machinery that looks at annotations and
> > causes Proxy classes to be generated into dynamic modules.
> >
> > Ioi - I suspect the restriction on creating dynamic modules in the
> > dump phase may be too restrictive. The full module graph dumping
> > should only be concerned with the boot layer.
> >
> > -Alan
>
>
> Hi Alan, thanks for the information. I've created
> https://bugs.openjdk.org/browse/JDK-8352187 to address this problem.
>
> I verified that the dynamic modules created by the dynamic proxies
> always have a null for its ModuleLayer. Also, there are no APIs for
> adding new modules into the boot layer (after the boot layer has been
> initialized), so the usage of ProxyBuilder.getDynamicModule() shouldn't
> cause problems for CDS.
>
>
> https://github.com/openjdk/jdk/blob/38499b3fbfcd22252ddf860d42b9eb0bf6f77235/src/java.base/share/classes/jdk/internal/module/Modules.java#L76-L82
>
> https://github.com/openjdk/jdk/blob/38499b3fbfcd22252ddf860d42b9eb0bf6f77235/src/java.base/share/classes/java/lang/System.java#L2033-L2037
>
> Thanks
>
> - Ioi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20250325/092463f7/attachment.htm>