Help to identify provenance of a warning

[adinn]

Hi all,

I have noticed some errors in the wildfly test suite when using new functionality added in jdk14. These relate to the  support I added to the JVM/JDK for mapping non-volatile RAM into a ByteBuffer. The problem does not appear to be with the ByteBuffer code itself. It appears to relate to the presence of a new BufferPoolMXBean in the list of buffer pool  beans returned by ManagementFactory.getPlatformMXBeans().

The error message associated with the test failures is

ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
    ("core-service" => "platform-mbean"),
    ("type" => "buffer-pool"),
    ("name" => "mapped_-_'non-volatile_memory'")
]) - failure description: "WFLYPMB0005: No BufferPoolMXBean with name mapped_-_'non-volatile_memory' currently exists"

Something in the bowels of Wildfly (or one of the components it drives) is finding the new MXBean and writing an error.

This is causing test failures in cases where the tests expects a specific success output to be written to System.out/err. One such example is test ClientCompatibilityUnitTestCase in the o.j.a.test.integration.management.api package hierarchy (under testsuite/integration/basic). I'd really like to know where this error is coming from and identify what would be needed to correct the code so that it either

  i) ignores the extra BufferPoolMXBean or

  ii) does something appropriate to respond to its presence (as it does for the existing "mapped" bean).

So, can anyone shed some light?

regards,

Andrew Dinn

[ctomc]

Hey Andrew,

It is interesting this code fails, as it was mostly made to handle new / different mbeans children.

Anyhow, exception comes from wildfly-core/BufferPoolMXBeanAttributeHandler.java at master · wildfly/wildfly-core · GitHub

It complains when mbean is not registered, even if it exists when you list it.

maybe there should be extra isRegistered() check when adding it to possible children list

wildfly-core/BufferPoolMXBeanResource.java at master · wildfly/wildfly-core · GitHub

Hope this help, it has been a while since I worked on that code..

[adinn]

Aha! I think I can see where the problem lies.

In BufferPoolMXBeanResource we have:

            Set names = ManagementFactory.getPlatformMBeanServer().queryNames(pattern, null);
            for (ObjectName on : names) {
                result.add(escapeMBeanName(on.getKeyProperty(ModelDescriptionConstants.NAME)));
            }

While in BufferPoolMXBeanResourceAttributeHandler we have:

        final ObjectName objectName = PlatformMBeanUtil.getObjectNameWithNameKey(PlatformMBeanConstants.BUFFER_POOL_MXBEAN_DOMAIN_TYPE, bpName);
        if (!ManagementFactory.getPlatformMBeanServer().isRegistered(objectName)) {

So, I think the problem is that the name needs to be passed back to that isRegistered call unescaped:

        final ObjectName objectName = PlatformMBeanUtil.getObjectNameWithNameKey(PlatformMBeanConstants.BUFFER_POOL_MXBEAN_DOMAIN_TYPE, bpName);
        if (!ManagementFactory.getPlatformMBeanServer().isRegistered(unescapeMBeanName(objectName))) {

That accords with the two '_' characters that appear in the error report:

     ("name" => "mapped_-_'non-volatile_memory'")

Do you want me to raise a JIRA? Or can you do that?

regards,

Andrew Dinn

[ctomc]

go ahead and create it.

thank you.