3 Replies Latest reply on Oct 11, 2019 10:08 AM by ctomc

Help to identify provenance of a warning

adinn Oct 11, 2019 5:51 AM

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

1. Re: Help to identify provenance of a warning

ctomc Oct 11, 2019 6:07 AM (in response to adinn)

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..
Actions

2. Re: Help to identify provenance of a warning

adinn Oct 11, 2019 7:20 AM (in response to ctomc)

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

3. Re: Help to identify provenance of a warning

ctomc Oct 11, 2019 10:08 AM (in response to adinn)

go ahead and create it.

thank you.
Actions

Go to original post