10:41 a.m.
I'm seeing strange JMX attributes when looking at domain mode and its MBeans.
In short, if a host wildfly server is up and running, there is no status in the
"server" MBean but there is status in the "server-config" MBean. When
the server is down, there is serverStatus in the "server" MBean as well as in
the "server-config" MBean.
Running a stock, out-of-box WildFly 11.0.0.Final using "domain.sh":
1. SERVER-ONE:
1a. MBean "jboss.as:host=master,server-config=server-one" has attribute
"status" of value "STARTED".
1b. MBean "jboss.as:host=master,server=server-one" has no attributes at all -
jconsole shows me no attributes for this MBean
2. SERVER-TWO:
2a. MBean "jboss.as:host=master,server-config=server-two" has attribute
"status" of value "STARTED".
2b. MBean "jboss.as:host=master,server=server-two" has no attributes at all -
jconsole shows me no attributes for this MBean
3. SERVER-THREE:
3a. MBean "jboss.as:host=master,server-config=server-three" has attribute
"status" of value "DISABLED".
3b. MBean "jboss.as:host=master,server=server-three" interestingly has attribute
"serverState" of value "STOPPED"
This doesn't make sense to me. I believe the "server" MBean for a started
server should have a serverState of values something like "running" or
"restart-required" or "reload-required". But instead, they don't
have any attributes at all.
Thoughts?
2:44 p.m.
Once a managed server is launched and registers with the HC the 'server'
resources are just proxies to the remote process. To access the attributes
of those resources you'd have to proxy to the remote process, which happens
transparently with WildFly management but which we don't support for JMX.
Probably we shouldn't expose the mbean at all, although that may be easier
said than done.
When the server isn't launched yet there's a kind of non-proxy placeholder
resource for it on the HC that is the registration point for ops like
start (which is why a resource even exists.) It exposes a few minimal
attributes, which seemed like a minor nice thing to do but I can see how it
can be confusing:
[domain@localhost:9990 server=server-three] ls -l
ATTRIBUTE VALUE TYPE
launch-type DOMAIN STRING
runtime-configuration-state stopped STRING
server-state STOPPED STRING
It seems a bunch of us have been getting wildfly-dev mails routed to our
spam folders, so apologies if we seem to be ignoring things.
On Mon, Nov 20, 2017 at 10:41 AM, John Mazzitelli <mazz(a)redhat.com> wrote:
I'm seeing strange JMX attributes when looking at domain mode and
its
MBeans.
In short, if a host wildfly server is up and running, there is no status
in the "server" MBean but there is status in the "server-config"
MBean.
When the server is down, there is serverStatus in the "server" MBean as
well as in the "server-config" MBean.
Running a stock, out-of-box WildFly 11.0.0.Final using "domain.sh":
1. SERVER-ONE:
1a. MBean "jboss.as:host=master,server-config=server-one" has attribute
"status" of value "STARTED".
1b. MBean "jboss.as:host=master,server=server-one" has no attributes at
all - jconsole shows me no attributes for this MBean
2. SERVER-TWO:
2a. MBean "jboss.as:host=master,server-config=server-two" has attribute
"status" of value "STARTED".
2b. MBean "jboss.as:host=master,server=server-two" has no attributes at
all - jconsole shows me no attributes for this MBean
3. SERVER-THREE:
3a. MBean "jboss.as:host=master,server-config=server-three" has attribute
"status" of value "DISABLED".
3b. MBean "jboss.as:host=master,server=server-three" interestingly has
attribute "serverState" of value "STOPPED"
This doesn't make sense to me. I believe the "server" MBean for a started
server should have a serverState of values something like "running" or
"restart-required" or "reload-required". But instead, they don't
have any
attributes at all.
Thoughts?
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
2552
days inactive
2560
days old
1 comments
2 participants
participants (2)
-
Brian Stansberry -
John Mazzitelli