[jboss-as7-dev] 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