Search code examples
jakarta-eeopenshiftjmxmbeanspayara

Missing AMX http-listener threadpool MBean of the Payara Server in OpenShift


as the title suggests, I'm trying to read an AMX mbean from Payara server (not the micro). Specifically it is the bean: amx:pp=/mon/server-mon[server],type=thread-pool-mon,name=network/http-listener-2/thread-pool.

This works locally, I checked the bean there (with JConsole) and can also read its value. But if it is deployed to OpenShift, this bean is no longer present. There are only the beans for admin-listener and monitoring-listener left. Checked via a OpenShift Jolokia interface which is similar to the JConsole.

Even with a missing bean the server is responding.

Both locally and in OpenShift the monitoring level "Thread Pool" of Payara is set to HIGH.

I noticed the very strange behavior, that some deployments have the mbean without changing the image. This behavior cannot really be reproduced, some deployments have the bean, others do not.

I'm a little lost here, does anyone have any idea why the bean is not there? I would be very grateful for any help.

Edit:
I added an image with the monitoring Levels: Monitoring Levels


Solution

  • I have experienced exactly the same problem and found (unfortunately only) a workaround. We were using Payara in version 4.1.2.184 and OpenShift master in version 3.6.173.

    A few additional observations:

    1. Monitoring module amx:pp=/mon/server-mon[server],type=thread-pool-mon is enabled by setting monitoring level to HIGH in the Http service object, not Thread pool. The latter is responsible for executor services, namely amx:pp=/mon/server-mon[server],type=thread-pool-mon.
    2. The incident when the monitoring level is set to HIGH, but the module is missing happens only, when the monitoring level is set since startup.

    The above lead to a natural conclusion, that when you set the monitoring level of the Http service to OFF and then immediately after to HIGH, the module appeared and provided correct statistics. The workaround in our case was executing those steps programatically after Payara's startup for every module we were interested in that had its monitoring level already set to HIGH.

    Unfortunately we still do not know the root cause.