Re: [jboss-as7-dev] JMX Facade

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