JMX Facade

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

JMX Facade

kkhan
The ongoing work for the JMX facade to the management model lives here: https://github.com/kabir/jboss-as/commits/jmx-facade

I'm still working through a few things before this is complete. I've included a description of how this works, along with some assumptions, things I came across when doing this and some questions.

To set up the management mbean stuff, I have added an optional element called 'show-model' to the jmx subsystem:
        <subsystem xmlns="urn:jboss:domain:jmx:1.0" show-model="true">
            <jmx-connector registry-binding="jmx-connector-registry" server-binding="jmx-connector-server" />
        </subsystem>
The default value is 'false', do I need to bump up the schema version number in this case (it is backwards compatible). If 'true' I wrap the mbean server in a similar way to TcclMBeanServer and look at the management model, i.e. no mbeans are actually created.

In brief how it works is that every resource in the model has an associated MBean in the 'jboss.model' domain , so for example '/subsystem=jmx' becomes 'jboss.model:subsystem=jmx'. All MBeans are described using OpenMBeanInfo.
The resource attributes become attributes on that mbean, and operations become operations on that mbean. An exception to the operations are the standard 'add' operations, so if you want to invoke '/subsystem=foo/child=blah:add()', the 'add' method lives on the parent MBean instead, so you would invoke the 'add-child' operation on 'jboss.model:subsystem=foo'.

The root of the model is registered under 'jboss.model:type=root'.

The types of attributes and operation parameters are defined using the open mbean types. For simple attributes where 'type=INT', that becomes an open mbean SimpleType.INT and so on. More Complex types are also handled, for example;
* {type=>LIST,value-type=>STRING} becomes a String[] (i.e. an ArrayType where the element type is SimpleType.STRING)
* {type=>OBJECT,value-type=>LONG} becomes a map represented by TabularType, where the index is called 'key' and each entry is a CompositeData containing the key under 'key' and the value under 'value'.
* Complex objects, such as {type=>OBJECT,value-type=>{{one=>{type=STRING},{two=>{type=INT}}} become a CompositeData where 'one' has the type SimpleType.STRING and 'two' has the type SImpleType.INT.

I still have to handle ModelType.PROPERTY, I left that until the end - I think this will become a CompositeData. I still need to look where PROPERTY is used in the model and see if we need to force those to have a VALUE_TYPE or if String can be assumed.

I am not inheriting any of the global operations at the moment (read-attribute, read-resource-description etc.), and am not sure if it makes to include them even in 'jboss.model:type=root' since they are detyped model specific, most of the information from these ops is available in other ways via jmx. I still need to verify that all mbeans can be described in AS, but I've already seen that these global ops need some work to get them to work since the root mbean fails on those.

I am not doing anything to handle operations that have more than one REPLY_PROPERTIES, I guess if they do I should roll them into a CompositeData?

I noticed one thing when using jconsole. If you attach to a 'local' process we never hit my management model wrapper or TcclMBeanServer, that only happens if you connect to localhost:1090 so it comes in via the connector. I need to look at this part of the spec but maybe an MBeanServerDelegate/MBeanServerFactory or something could be used so that the behaviour always is available.

I am not allowing notification listeners to be registered under 'jboss.model:'. It might be possible to add another configuration persister to trap these events, but since (I think) we only really know if the model has changed or not, not what has actually changed, I think that would add overhead at the moment until notifications are added to the core management model.

I am not handling the query parameter to queryMBeans(ObjectName name, QueryExp query) or queryNames(ObjectName name, QueryExp query) in the wrapper, only the query parameter.

Due to jmx using 'proper' method signatures where the order of the operation parameters is important, and the detyped management model using request-properties keyed by name, if the management model changes the order of parameters between releases jmx clients will break.



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX Facade

kkhan
Also, at the moment this is only tried out in standalone servers. When running in a domain, I suspect we would want to expose the DC's model in jmx and hide the individual servers?
On 22 Aug 2011, at 17:50, Kabir Khan wrote:

> The ongoing work for the JMX facade to the management model lives here: https://github.com/kabir/jboss-as/commits/jmx-facade
>
> I'm still working through a few things before this is complete. I've included a description of how this works, along with some assumptions, things I came across when doing this and some questions.
>
> To set up the management mbean stuff, I have added an optional element called 'show-model' to the jmx subsystem:
>        <subsystem xmlns="urn:jboss:domain:jmx:1.0" show-model="true">
>            <jmx-connector registry-binding="jmx-connector-registry" server-binding="jmx-connector-server" />
>        </subsystem>
> The default value is 'false', do I need to bump up the schema version number in this case (it is backwards compatible). If 'true' I wrap the mbean server in a similar way to TcclMBeanServer and look at the management model, i.e. no mbeans are actually created.
>
> In brief how it works is that every resource in the model has an associated MBean in the 'jboss.model' domain , so for example '/subsystem=jmx' becomes 'jboss.model:subsystem=jmx'. All MBeans are described using OpenMBeanInfo.
> The resource attributes become attributes on that mbean, and operations become operations on that mbean. An exception to the operations are the standard 'add' operations, so if you want to invoke '/subsystem=foo/child=blah:add()', the 'add' method lives on the parent MBean instead, so you would invoke the 'add-child' operation on 'jboss.model:subsystem=foo'.
>
> The root of the model is registered under 'jboss.model:type=root'.
>
> The types of attributes and operation parameters are defined using the open mbean types. For simple attributes where 'type=INT', that becomes an open mbean SimpleType.INT and so on. More Complex types are also handled, for example;
> * {type=>LIST,value-type=>STRING} becomes a String[] (i.e. an ArrayType where the element type is SimpleType.STRING)
> * {type=>OBJECT,value-type=>LONG} becomes a map represented by TabularType, where the index is called 'key' and each entry is a CompositeData containing the key under 'key' and the value under 'value'.
> * Complex objects, such as {type=>OBJECT,value-type=>{{one=>{type=STRING},{two=>{type=INT}}} become a CompositeData where 'one' has the type SimpleType.STRING and 'two' has the type SImpleType.INT.
>
> I still have to handle ModelType.PROPERTY, I left that until the end - I think this will become a CompositeData. I still need to look where PROPERTY is used in the model and see if we need to force those to have a VALUE_TYPE or if String can be assumed.
>
> I am not inheriting any of the global operations at the moment (read-attribute, read-resource-description etc.), and am not sure if it makes to include them even in 'jboss.model:type=root' since they are detyped model specific, most of the information from these ops is available in other ways via jmx. I still need to verify that all mbeans can be described in AS, but I've already seen that these global ops need some work to get them to work since the root mbean fails on those.
>
> I am not doing anything to handle operations that have more than one REPLY_PROPERTIES, I guess if they do I should roll them into a CompositeData?
>
> I noticed one thing when using jconsole. If you attach to a 'local' process we never hit my management model wrapper or TcclMBeanServer, that only happens if you connect to localhost:1090 so it comes in via the connector. I need to look at this part of the spec but maybe an MBeanServerDelegate/MBeanServerFactory or something could be used so that the behaviour always is available.
>
> I am not allowing notification listeners to be registered under 'jboss.model:'. It might be possible to add another configuration persister to trap these events, but since (I think) we only really know if the model has changed or not, not what has actually changed, I think that would add overhead at the moment until notifications are added to the core management model.
>
> I am not handling the query parameter to queryMBeans(ObjectName name, QueryExp query) or queryNames(ObjectName name, QueryExp query) in the wrapper, only the query parameter.
>
> Due to jmx using 'proper' method signatures where the order of the operation parameters is important, and the detyped management model using request-properties keyed by name, if the management model changes the order of parameters between releases jmx clients will break.
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX Facade

Brian Stansberry
In reply to this post by kkhan
On 8/22/11 11:50 AM, Kabir Khan wrote:

> The ongoing work for the JMX facade to the management model lives here: https://github.com/kabir/jboss-as/commits/jmx-facade
>
> I'm still working through a few things before this is complete. I've included a description of how this works, along with some assumptions, things I came across when doing this and some questions.
>
> To set up the management mbean stuff, I have added an optional element called 'show-model' to the jmx subsystem:
>          <subsystem xmlns="urn:jboss:domain:jmx:1.0" show-model="true">
>              <jmx-connector registry-binding="jmx-connector-registry" server-binding="jmx-connector-server" />
>          </subsystem>
> The default value is 'false', do I need to bump up the schema version number in this case (it is backwards compatible). If 'true' I wrap the mbean server in a similar way to TcclMBeanServer and look at the management model, i.e. no mbeans are actually created.
>

If someone uses this attribute in a document applied to a 7.0.x servers,
I assume it will fail to parse. So that indicates a schema bump. (It's
the right thing to do anyway.)

> In brief how it works is that every resource in the model has an associated MBean in the 'jboss.model' domain , so for example '/subsystem=jmx' becomes 'jboss.model:subsystem=jmx'.

We need a different domain. Why not jboss.as?  (Hmm, I can already hear
the calls for jboss.eap).

All MBeans are described using OpenMBeanInfo.
> The resource attributes become attributes on that mbean, and operations become operations on that mbean. An exception to the operations are the standard 'add' operations, so if you want to invoke '/subsystem=foo/child=blah:add()', the 'add' method lives on the parent MBean instead, so you would invoke the 'add-child' operation on 'jboss.model:subsystem=foo'.
>
> The root of the model is registered under 'jboss.model:type=root'.
>

Don't use 'type'. Whatever you use becomes a reserved word that can't be
a key in any resource address element. We need something that no one is
going to use. (The platform mbeans I'm exposing use 'type' in their
address because the JDK uses it in their ObjectNames).

Probably "xxx=domain" or "xxx=standalone" to properly separate the
managed domain and standalone cases.

<goes-to-think-of-a-better-"xxx"/>

> The types of attributes and operation parameters are defined using the open mbean types. For simple attributes where 'type=INT', that becomes an open mbean SimpleType.INT and so on. More Complex types are also handled, for example;
> * {type=>LIST,value-type=>STRING} becomes a String[] (i.e. an ArrayType where the element type is SimpleType.STRING)
> * {type=>OBJECT,value-type=>LONG} becomes a map represented by TabularType, where the index is called 'key' and each entry is a CompositeData containing the key under 'key' and the value under 'value'.
> * Complex objects, such as {type=>OBJECT,value-type=>{{one=>{type=STRING},{two=>{type=INT}}} become a CompositeData where 'one' has the type SimpleType.STRING and 'two' has the type SImpleType.INT.
>
> I still have to handle ModelType.PROPERTY, I left that until the end - I think this will become a CompositeData. I still need to look where PROPERTY is used in the model and see if we need to force those to have a VALUE_TYPE or if String can be assumed.
>

I can't think of any reason they shouldn't have a value type. I doubt
any actually exist.

> I am not inheriting any of the global operations at the moment (read-attribute, read-resource-description etc.), and am not sure if it makes to include them even in 'jboss.model:type=root' since they are detyped model specific, most of the information from these ops is available in other ways via jmx.

I could see providing read-children-names and read-children-types but
none of the others.

> I still need to verify that all mbeans can be described in AS, but I've already seen that these global ops need some work to get them to work since the root mbean fails on those.
>
> I am not doing anything to handle operations that have more than one REPLY_PROPERTIES, I guess if they do I should roll them into a CompositeData?
>

A return value should be modeled the same as an operation parameter.

> I noticed one thing when using jconsole. If you attach to a 'local' process we never hit my management model wrapper or TcclMBeanServer, that only happens if you connect to localhost:1090 so it comes in via the connector. I need to look at this part of the spec but maybe an MBeanServerDelegate/MBeanServerFactory or something could be used so that the behaviour always is available.
>
> I am not allowing notification listeners to be registered under 'jboss.model:'. It might be possible to add another configuration persister to trap these events, but since (I think) we only really know if the model has changed or not, not what has actually changed, I think that would add overhead at the moment until notifications are added to the core management model.
>

Agreed.

> I am not handling the query parameter to queryMBeans(ObjectName name, QueryExp query) or queryNames(ObjectName name, QueryExp query) in the wrapper, only the query parameter.
>

I don't follow. :)

> Due to jmx using 'proper' method signatures where the order of the operation parameters is important, and the detyped management model using request-properties keyed by name, if the management model changes the order of parameters between releases jmx clients will break.
>

So you're getting the order of parameters from the order they appear in
the operation description metadata?

>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX Facade

Brian Stansberry
In reply to this post by kkhan
On 8/22/11 11:56 AM, Kabir Khan wrote:
> Also, at the moment this is only tried out in standalone servers. When running in a domain, I suspect we would want to expose the DC's model in jmx and hide the individual servers?

Would exposing the servers (and remote HCs from the DC) be significantly
harder?

> On 22 Aug 2011, at 17:50, Kabir Khan wrote:
>
>> The ongoing work for the JMX facade to the management model lives here: https://github.com/kabir/jboss-as/commits/jmx-facade
>>
>> I'm still working through a few things before this is complete. I've included a description of how this works, along with some assumptions, things I came across when doing this and some questions.
>>
>> To set up the management mbean stuff, I have added an optional element called 'show-model' to the jmx subsystem:
>>         <subsystem xmlns="urn:jboss:domain:jmx:1.0" show-model="true">
>>             <jmx-connector registry-binding="jmx-connector-registry" server-binding="jmx-connector-server" />
>>         </subsystem>
>> The default value is 'false', do I need to bump up the schema version number in this case (it is backwards compatible). If 'true' I wrap the mbean server in a similar way to TcclMBeanServer and look at the management model, i.e. no mbeans are actually created.
>>
>> In brief how it works is that every resource in the model has an associated MBean in the 'jboss.model' domain , so for example '/subsystem=jmx' becomes 'jboss.model:subsystem=jmx'. All MBeans are described using OpenMBeanInfo.
>> The resource attributes become attributes on that mbean, and operations become operations on that mbean. An exception to the operations are the standard 'add' operations, so if you want to invoke '/subsystem=foo/child=blah:add()', the 'add' method lives on the parent MBean instead, so you would invoke the 'add-child' operation on 'jboss.model:subsystem=foo'.
>>
>> The root of the model is registered under 'jboss.model:type=root'.
>>
>> The types of attributes and operation parameters are defined using the open mbean types. For simple attributes where 'type=INT', that becomes an open mbean SimpleType.INT and so on. More Complex types are also handled, for example;
>> * {type=>LIST,value-type=>STRING} becomes a String[] (i.e. an ArrayType where the element type is SimpleType.STRING)
>> * {type=>OBJECT,value-type=>LONG} becomes a map represented by TabularType, where the index is called 'key' and each entry is a CompositeData containing the key under 'key' and the value under 'value'.
>> * Complex objects, such as {type=>OBJECT,value-type=>{{one=>{type=STRING},{two=>{type=INT}}} become a CompositeData where 'one' has the type SimpleType.STRING and 'two' has the type SImpleType.INT.
>>
>> I still have to handle ModelType.PROPERTY, I left that until the end - I think this will become a CompositeData. I still need to look where PROPERTY is used in the model and see if we need to force those to have a VALUE_TYPE or if String can be assumed.
>>
>> I am not inheriting any of the global operations at the moment (read-attribute, read-resource-description etc.), and am not sure if it makes to include them even in 'jboss.model:type=root' since they are detyped model specific, most of the information from these ops is available in other ways via jmx. I still need to verify that all mbeans can be described in AS, but I've already seen that these global ops need some work to get them to work since the root mbean fails on those.
>>
>> I am not doing anything to handle operations that have more than one REPLY_PROPERTIES, I guess if they do I should roll them into a CompositeData?
>>
>> I noticed one thing when using jconsole. If you attach to a 'local' process we never hit my management model wrapper or TcclMBeanServer, that only happens if you connect to localhost:1090 so it comes in via the connector. I need to look at this part of the spec but maybe an MBeanServerDelegate/MBeanServerFactory or something could be used so that the behaviour always is available.
>>
>> I am not allowing notification listeners to be registered under 'jboss.model:'. It might be possible to add another configuration persister to trap these events, but since (I think) we only really know if the model has changed or not, not what has actually changed, I think that would add overhead at the moment until notifications are added to the core management model.
>>
>> I am not handling the query parameter to queryMBeans(ObjectName name, QueryExp query) or queryNames(ObjectName name, QueryExp query) in the wrapper, only the query parameter.
>>
>> Due to jmx using 'proper' method signatures where the order of the operation parameters is important, and the detyped management model using request-properties keyed by name, if the management model changes the order of parameters between releases jmx clients will break.
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX Facade

kkhan
In reply to this post by Brian Stansberry
On 22 Aug 2011, at 22:20, Brian Stansberry wrote:

> On 8/22/11 11:56 AM, Kabir Khan wrote:
>> Also, at the moment this is only tried out in standalone servers. When running in a domain, I suspect we would want to expose the DC's model in jmx and hide the individual servers?
>
> Would exposing the servers (and remote HCs from the DC) be significantly
> harder?

If I understood you correctly, I don't think the DC/HC exposes JMX at the moment. I can set it up during the bootstrap. Although, we have other things like remoting which need special voodoo on the DC/HC but happen normally on the servers. Once that is done, I don't think it will be a lot harder, I just need to walk the model 'better'.

>
On 22 Aug 2011, at 22:06, Brian Stansberry wrote:

> On 8/22/11 11:50 AM, Kabir Khan wrote:
>> The ongoing work for the JMX facade to the management model lives here: https://github.com/kabir/jboss-as/commits/jmx-facade
>>
>> I'm still working through a few things before this is complete. I've included a description of how this works, along with some assumptions, things I came across when doing this and some questions.
>>
>> To set up the management mbean stuff, I have added an optional element called 'show-model' to the jmx subsystem:
>>         <subsystem xmlns="urn:jboss:domain:jmx:1.0" show-model="true">
>>             <jmx-connector registry-binding="jmx-connector-registry" server-binding="jmx-connector-server" />
>>         </subsystem>
>> The default value is 'false', do I need to bump up the schema version number in this case (it is backwards compatible). If 'true' I wrap the mbean server in a similar way to TcclMBeanServer and look at the management model, i.e. no mbeans are actually created.
>>
>
> If someone uses this attribute in a document applied to a 7.0.x servers,
> I assume it will fail to parse. So that indicates a schema bump. (It's
> the right thing to do anyway.)

ok, "urn:jboss:domain:jmx:1.1" or "urn:jboss:domain:jmx:2.0"?

>
>> In brief how it works is that every resource in the model has an associated MBean in the 'jboss.model' domain , so for example '/subsystem=jmx' becomes 'jboss.model:subsystem=jmx'.
>
> We need a different domain. Why not jboss.as?  (Hmm, I can already hear
> the calls for jboss.eap).
>

A trivial change, I'll do whatever you decide :-) I kind of liked jboss.model though, other things might

> All MBeans are described using OpenMBeanInfo.
>> The resource attributes become attributes on that mbean, and operations become operations on that mbean. An exception to the operations are the standard 'add' operations, so if you want to invoke '/subsystem=foo/child=blah:add()', the 'add' method lives on the parent MBean instead, so you would invoke the 'add-child' operation on 'jboss.model:subsystem=foo'.
>>
>> The root of the model is registered under 'jboss.model:type=root'.
>>
>
> Don't use 'type'. Whatever you use becomes a reserved word that can't be
> a key in any resource address element. We need something that no one is
> going to use. (The platform mbeans I'm exposing use 'type' in their
> address because the JDK uses it in their ObjectNames).
>
> Probably "xxx=domain" or "xxx=standalone" to properly separate the
> managed domain and standalone cases.
>
> <goes-to-think-of-a-better-"xxx"/>

root=domain and root=standalone? or even
management-root=domain and management-root=standalone

>
>> The types of attributes and operation parameters are defined using the open mbean types. For simple attributes where 'type=INT', that becomes an open mbean SimpleType.INT and so on. More Complex types are also handled, for example;
>> * {type=>LIST,value-type=>STRING} becomes a String[] (i.e. an ArrayType where the element type is SimpleType.STRING)
>> * {type=>OBJECT,value-type=>LONG} becomes a map represented by TabularType, where the index is called 'key' and each entry is a CompositeData containing the key under 'key' and the value under 'value'.
>> * Complex objects, such as {type=>OBJECT,value-type=>{{one=>{type=STRING},{two=>{type=INT}}} become a CompositeData where 'one' has the type SimpleType.STRING and 'two' has the type SImpleType.INT.
>>
>> I still have to handle ModelType.PROPERTY, I left that until the end - I think this will become a CompositeData. I still need to look where PROPERTY is used in the model and see if we need to force those to have a VALUE_TYPE or if String can be assumed.
>>
>
> I can't think of any reason they shouldn't have a value type. I doubt
> any actually exist.

Ok, on that note when something with type=OBJECT,value-type=UNDEFINED is returned I use a JSON string. I think maybe the model should be fixed where possible to avoid this horrible fallback

>
>> I am not inheriting any of the global operations at the moment (read-attribute, read-resource-description etc.), and am not sure if it makes to include them even in 'jboss.model:type=root' since they are detyped model specific, most of the information from these ops is available in other ways via jmx.
>
> I could see providing read-children-names and read-children-types but
> none of the others.
>
>> I still need to verify that all mbeans can be described in AS, but I've already seen that these global ops need some work to get them to work since the root mbean fails on those.
>>
>> I am not doing anything to handle operations that have more than one REPLY_PROPERTIES, I guess if they do I should roll them into a CompositeData?
>>
>
> A return value should be modeled the same as an operation parameter.
>
>> I noticed one thing when using jconsole. If you attach to a 'local' process we never hit my management model wrapper or TcclMBeanServer, that only happens if you connect to localhost:1090 so it comes in via the connector. I need to look at this part of the spec but maybe an MBeanServerDelegate/MBeanServerFactory or something could be used so that the behaviour always is available.
>>
>> I am not allowing notification listeners to be registered under 'jboss.model:'. It might be possible to add another configuration persister to trap these events, but since (I think) we only really know if the model has changed or not, not what has actually changed, I think that would add overhead at the moment until notifications are added to the core management model.
>>
>
> Agreed.
>
>> I am not handling the query parameter to queryMBeans(ObjectName name, QueryExp query) or queryNames(ObjectName name, QueryExp query) in the wrapper, only the query parameter.
>>
>
> I don't follow. :)
You can currently do connection.queryMBeans(new ObjectName{"jboss.model:*", null)  to only get certain mbeans filtered on name. Those MBeanServer methods also allow a second parameter to filter on attribute values, that part is not implemented.

>
>> Due to jmx using 'proper' method signatures where the order of the operation parameters is important, and the detyped management model using request-properties keyed by name, if the management model changes the order of parameters between releases jmx clients will break.
>>
>
> So you're getting the order of parameters from the order they appear in
> the operation description metadata?
Yes, that is how that works at present. Maybe it would be better to always use a composite data to have the name->value bindings, but that might make jconsole look a bit weird. The OpenMBeanParameterInfo[] does show what the different parameters are though
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX Facade

Brian Stansberry
On 8/23/11 4:50 AM, Kabir Khan wrote:

> On 22 Aug 2011, at 22:20, Brian Stansberry wrote:
>
>> On 8/22/11 11:56 AM, Kabir Khan wrote:
>>> Also, at the moment this is only tried out in standalone servers. When running in a domain, I suspect we would want to expose the DC's model in jmx and hide the individual servers?
>>
>> Would exposing the servers (and remote HCs from the DC) be significantly
>> harder?
>
> If I understood you correctly, I don't think the DC/HC exposes JMX at the moment. I can set it up during the bootstrap. Although, we have other things like remoting which need special voodoo on the DC/HC but happen normally on the servers. Once that is done, I don't think it will be a lot harder, I just need to walk the model 'better'.
>

There are things you can't do via a JMX interface on a DC/HC --
specifically, specify a rollout plan for how any write ops should be
applied to servers. (Which is why the whole thing isn't JMX-based ;) --
that and composite ops.) So in practice I don't know how much folks will
be using JMX for writes.

For reads though, things like monitoring, I expect there will be quite a
few users who prefer to use JMX-based tools.

>>
> On 22 Aug 2011, at 22:06, Brian Stansberry wrote:
>
>> On 8/22/11 11:50 AM, Kabir Khan wrote:
>>> The ongoing work for the JMX facade to the management model lives here: https://github.com/kabir/jboss-as/commits/jmx-facade
>>>
>>> I'm still working through a few things before this is complete. I've included a description of how this works, along with some assumptions, things I came across when doing this and some questions.
>>>
>>> To set up the management mbean stuff, I have added an optional element called 'show-model' to the jmx subsystem:
>>>          <subsystem xmlns="urn:jboss:domain:jmx:1.0" show-model="true">
>>>              <jmx-connector registry-binding="jmx-connector-registry" server-binding="jmx-connector-server" />
>>>          </subsystem>
>>> The default value is 'false', do I need to bump up the schema version number in this case (it is backwards compatible). If 'true' I wrap the mbean server in a similar way to TcclMBeanServer and look at the management model, i.e. no mbeans are actually created.
>>>
>>
>> If someone uses this attribute in a document applied to a 7.0.x servers,
>> I assume it will fail to parse. So that indicates a schema bump. (It's
>> the right thing to do anyway.)
>
> ok, "urn:jboss:domain:jmx:1.1" or "urn:jboss:domain:jmx:2.0"?
>
>>
>>> In brief how it works is that every resource in the model has an associated MBean in the 'jboss.model' domain , so for example '/subsystem=jmx' becomes 'jboss.model:subsystem=jmx'.
>>
>> We need a different domain. Why not jboss.as?  (Hmm, I can already hear
>> the calls for jboss.eap).
>>
>
> A trivial change, I'll do whatever you decide :-) I kind of liked jboss.model though, other things might
>
>> All MBeans are described using OpenMBeanInfo.
>>> The resource attributes become attributes on that mbean, and operations become operations on that mbean. An exception to the operations are the standard 'add' operations, so if you want to invoke '/subsystem=foo/child=blah:add()', the 'add' method lives on the parent MBean instead, so you would invoke the 'add-child' operation on 'jboss.model:subsystem=foo'.
>>>
>>> The root of the model is registered under 'jboss.model:type=root'.
>>>
>>
>> Don't use 'type'. Whatever you use becomes a reserved word that can't be
>> a key in any resource address element. We need something that no one is
>> going to use. (The platform mbeans I'm exposing use 'type' in their
>> address because the JDK uses it in their ObjectNames).
>>
>> Probably "xxx=domain" or "xxx=standalone" to properly separate the
>> managed domain and standalone cases.
>>
>> <goes-to-think-of-a-better-"xxx"/>
>
> root=domain and root=standalone? or even
> management-root=domain and management-root=standalone
>
>>
>>> The types of attributes and operation parameters are defined using the open mbean types. For simple attributes where 'type=INT', that becomes an open mbean SimpleType.INT and so on. More Complex types are also handled, for example;
>>> * {type=>LIST,value-type=>STRING} becomes a String[] (i.e. an ArrayType where the element type is SimpleType.STRING)
>>> * {type=>OBJECT,value-type=>LONG} becomes a map represented by TabularType, where the index is called 'key' and each entry is a CompositeData containing the key under 'key' and the value under 'value'.
>>> * Complex objects, such as {type=>OBJECT,value-type=>{{one=>{type=STRING},{two=>{type=INT}}} become a CompositeData where 'one' has the type SimpleType.STRING and 'two' has the type SImpleType.INT.
>>>
>>> I still have to handle ModelType.PROPERTY, I left that until the end - I think this will become a CompositeData. I still need to look where PROPERTY is used in the model and see if we need to force those to have a VALUE_TYPE or if String can be assumed.
>>>
>>
>> I can't think of any reason they shouldn't have a value type. I doubt
>> any actually exist.
>
> Ok, on that note when something with type=OBJECT,value-type=UNDEFINED is returned I use a JSON string. I think maybe the model should be fixed where possible to avoid this horrible fallback
>
>>
>>> I am not inheriting any of the global operations at the moment (read-attribute, read-resource-description etc.), and am not sure if it makes to include them even in 'jboss.model:type=root' since they are detyped model specific, most of the information from these ops is available in other ways via jmx.
>>
>> I could see providing read-children-names and read-children-types but
>> none of the others.
>>
>>> I still need to verify that all mbeans can be described in AS, but I've already seen that these global ops need some work to get them to work since the root mbean fails on those.
>>>
>>> I am not doing anything to handle operations that have more than one REPLY_PROPERTIES, I guess if they do I should roll them into a CompositeData?
>>>
>>
>> A return value should be modeled the same as an operation parameter.
>>
>>> I noticed one thing when using jconsole. If you attach to a 'local' process we never hit my management model wrapper or TcclMBeanServer, that only happens if you connect to localhost:1090 so it comes in via the connector. I need to look at this part of the spec but maybe an MBeanServerDelegate/MBeanServerFactory or something could be used so that the behaviour always is available.
>>>
>>> I am not allowing notification listeners to be registered under 'jboss.model:'. It might be possible to add another configuration persister to trap these events, but since (I think) we only really know if the model has changed or not, not what has actually changed, I think that would add overhead at the moment until notifications are added to the core management model.
>>>
>>
>> Agreed.
>>
>>> I am not handling the query parameter to queryMBeans(ObjectName name, QueryExp query) or queryNames(ObjectName name, QueryExp query) in the wrapper, only the query parameter.
>>>
>>
>> I don't follow. :)
> You can currently do connection.queryMBeans(new ObjectName{"jboss.model:*", null)  to only get certain mbeans filtered on name. Those MBeanServer methods also allow a second parameter to filter on attribute values, that part is not implemented.
>
>>
>>> Due to jmx using 'proper' method signatures where the order of the operation parameters is important, and the detyped management model using request-properties keyed by name, if the management model changes the order of parameters between releases jmx clients will break.
>>>
>>
>> So you're getting the order of parameters from the order they appear in
>> the operation description metadata?
> Yes, that is how that works at present. Maybe it would be better to always use a composite data to have the name->value bindings, but that might make jconsole look a bit weird. The OpenMBeanParameterInfo[] does show what the different parameters are though


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX Facade

Brian Stansberry
On 8/23/11 9:38 AM, Brian Stansberry wrote:

> On 8/23/11 4:50 AM, Kabir Khan wrote:
>> On 22 Aug 2011, at 22:20, Brian Stansberry wrote:
>>
>>> On 8/22/11 11:56 AM, Kabir Khan wrote:
>>>> Also, at the moment this is only tried out in standalone servers.
>>>> When running in a domain, I suspect we would want to expose the DC's
>>>> model in jmx and hide the individual servers?
>>>
>>> Would exposing the servers (and remote HCs from the DC) be significantly
>>> harder?
>>
>> If I understood you correctly, I don't think the DC/HC exposes JMX at
>> the moment. I can set it up during the bootstrap. Although, we have
>> other things like remoting which need special voodoo on the DC/HC but
>> happen normally on the servers. Once that is done, I don't think it
>> will be a lot harder, I just need to walk the model 'better'.
>>
>
> There are things you can't do via a JMX interface on a DC/HC --
> specifically, specify a rollout plan for how any write ops should be
> applied to servers. (Which is why the whole thing isn't JMX-based ;) --
> that and composite ops.) So in practice I don't know how much folks will
> be using JMX for writes.
>
> For reads though, things like monitoring, I expect there will be quite a
> few users who prefer to use JMX-based tools.
>

I was talking about this with Andy Miller today and he raised a good
point about priorities. JMX will never be a very good fit for managing a
DC/HC because of the rollout plan issue. So it really shouldn't be a
priority to work on providing it. The server stuff you've done is the
important part.

>>>
>> On 22 Aug 2011, at 22:06, Brian Stansberry wrote:
>>
>>> On 8/22/11 11:50 AM, Kabir Khan wrote:
>>>> The ongoing work for the JMX facade to the management model lives
>>>> here: https://github.com/kabir/jboss-as/commits/jmx-facade
>>>>
>>>> I'm still working through a few things before this is complete. I've
>>>> included a description of how this works, along with some
>>>> assumptions, things I came across when doing this and some questions.
>>>>
>>>> To set up the management mbean stuff, I have added an optional
>>>> element called 'show-model' to the jmx subsystem:
>>>> <subsystem xmlns="urn:jboss:domain:jmx:1.0" show-model="true">
>>>> <jmx-connector registry-binding="jmx-connector-registry"
>>>> server-binding="jmx-connector-server" />
>>>> </subsystem>
>>>> The default value is 'false', do I need to bump up the schema
>>>> version number in this case (it is backwards compatible). If 'true'
>>>> I wrap the mbean server in a similar way to TcclMBeanServer and look
>>>> at the management model, i.e. no mbeans are actually created.
>>>>
>>>
>>> If someone uses this attribute in a document applied to a 7.0.x servers,
>>> I assume it will fail to parse. So that indicates a schema bump. (It's
>>> the right thing to do anyway.)
>>
>> ok, "urn:jboss:domain:jmx:1.1" or "urn:jboss:domain:jmx:2.0"?
>>
>>>
>>>> In brief how it works is that every resource in the model has an
>>>> associated MBean in the 'jboss.model' domain , so for example
>>>> '/subsystem=jmx' becomes 'jboss.model:subsystem=jmx'.
>>>
>>> We need a different domain. Why not jboss.as? (Hmm, I can already hear
>>> the calls for jboss.eap).
>>>
>>
>> A trivial change, I'll do whatever you decide :-) I kind of liked
>> jboss.model though, other things might
>>
>>> All MBeans are described using OpenMBeanInfo.
>>>> The resource attributes become attributes on that mbean, and
>>>> operations become operations on that mbean. An exception to the
>>>> operations are the standard 'add' operations, so if you want to
>>>> invoke '/subsystem=foo/child=blah:add()', the 'add' method lives on
>>>> the parent MBean instead, so you would invoke the 'add-child'
>>>> operation on 'jboss.model:subsystem=foo'.
>>>>
>>>> The root of the model is registered under 'jboss.model:type=root'.
>>>>
>>>
>>> Don't use 'type'. Whatever you use becomes a reserved word that can't be
>>> a key in any resource address element. We need something that no one is
>>> going to use. (The platform mbeans I'm exposing use 'type' in their
>>> address because the JDK uses it in their ObjectNames).
>>>
>>> Probably "xxx=domain" or "xxx=standalone" to properly separate the
>>> managed domain and standalone cases.
>>>
>>> <goes-to-think-of-a-better-"xxx"/>
>>
>> root=domain and root=standalone? or even
>> management-root=domain and management-root=standalone
>>
>>>
>>>> The types of attributes and operation parameters are defined using
>>>> the open mbean types. For simple attributes where 'type=INT', that
>>>> becomes an open mbean SimpleType.INT and so on. More Complex types
>>>> are also handled, for example;
>>>> * {type=>LIST,value-type=>STRING} becomes a String[] (i.e. an
>>>> ArrayType where the element type is SimpleType.STRING)
>>>> * {type=>OBJECT,value-type=>LONG} becomes a map represented by
>>>> TabularType, where the index is called 'key' and each entry is a
>>>> CompositeData containing the key under 'key' and the value under
>>>> 'value'.
>>>> * Complex objects, such as
>>>> {type=>OBJECT,value-type=>{{one=>{type=STRING},{two=>{type=INT}}}
>>>> become a CompositeData where 'one' has the type SimpleType.STRING
>>>> and 'two' has the type SImpleType.INT.
>>>>
>>>> I still have to handle ModelType.PROPERTY, I left that until the end
>>>> - I think this will become a CompositeData. I still need to look
>>>> where PROPERTY is used in the model and see if we need to force
>>>> those to have a VALUE_TYPE or if String can be assumed.
>>>>
>>>
>>> I can't think of any reason they shouldn't have a value type. I doubt
>>> any actually exist.
>>
>> Ok, on that note when something with type=OBJECT,value-type=UNDEFINED
>> is returned I use a JSON string. I think maybe the model should be
>> fixed where possible to avoid this horrible fallback
>>
>>>
>>>> I am not inheriting any of the global operations at the moment
>>>> (read-attribute, read-resource-description etc.), and am not sure if
>>>> it makes to include them even in 'jboss.model:type=root' since they
>>>> are detyped model specific, most of the information from these ops
>>>> is available in other ways via jmx.
>>>
>>> I could see providing read-children-names and read-children-types but
>>> none of the others.
>>>
>>>> I still need to verify that all mbeans can be described in AS, but
>>>> I've already seen that these global ops need some work to get them
>>>> to work since the root mbean fails on those.
>>>>
>>>> I am not doing anything to handle operations that have more than one
>>>> REPLY_PROPERTIES, I guess if they do I should roll them into a
>>>> CompositeData?
>>>>
>>>
>>> A return value should be modeled the same as an operation parameter.
>>>
>>>> I noticed one thing when using jconsole. If you attach to a 'local'
>>>> process we never hit my management model wrapper or TcclMBeanServer,
>>>> that only happens if you connect to localhost:1090 so it comes in
>>>> via the connector. I need to look at this part of the spec but maybe
>>>> an MBeanServerDelegate/MBeanServerFactory or something could be used
>>>> so that the behaviour always is available.
>>>>
>>>> I am not allowing notification listeners to be registered under
>>>> 'jboss.model:'. It might be possible to add another configuration
>>>> persister to trap these events, but since (I think) we only really
>>>> know if the model has changed or not, not what has actually changed,
>>>> I think that would add overhead at the moment until notifications
>>>> are added to the core management model.
>>>>
>>>
>>> Agreed.
>>>
>>>> I am not handling the query parameter to queryMBeans(ObjectName
>>>> name, QueryExp query) or queryNames(ObjectName name, QueryExp query)
>>>> in the wrapper, only the query parameter.
>>>>
>>>
>>> I don't follow. :)
>> You can currently do connection.queryMBeans(new
>> ObjectName{"jboss.model:*", null) to only get certain mbeans filtered
>> on name. Those MBeanServer methods also allow a second parameter to
>> filter on attribute values, that part is not implemented.
>>
>>>
>>>> Due to jmx using 'proper' method signatures where the order of the
>>>> operation parameters is important, and the detyped management model
>>>> using request-properties keyed by name, if the management model
>>>> changes the order of parameters between releases jmx clients will
>>>> break.
>>>>
>>>
>>> So you're getting the order of parameters from the order they appear in
>>> the operation description metadata?
>> Yes, that is how that works at present. Maybe it would be better to
>> always use a composite data to have the name->value bindings, but that
>> might make jconsole look a bit weird. The OpenMBeanParameterInfo[]
>> does show what the different parameters are though
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev