Re: [jboss-as7-dev] Attributes, metrics, additional descriptive information for such

On 1/26/11 7:35 AM, Emanuel Muckenhuber wrote: > On 01/26/2011 01:18 AM, Brian Stansberry wrote: >> FYI I think this pretty much summarizes the various IRC etc discussions >> today about metrics. Thoughts? >> >> 1) Metrics are represented in the model description at the same level as >> "configuration" attributes. >> >> 2) Metrics are represented in a "read-resource" result the same as >> configuration attributes. >> >> 3) Metrics are stored in a ModelNodeRegistration in the same map as >> attributes >> a) but they need to have a custom read handler registered, as the >> default model-reading one won't work >> >> 4) Multi-server queries will not be done via the domain/host level >> resources. This eliminates the "expense" issue of treating metrics >> as attributes on a domain resource (expense due to need to read the >> metrics across all servers in order to >> generate the full result.) Instead, domain and host level resources will >> not have metrics, and attributes will just return >> the domain/host level value. >> > > This does seem to go a bit beyond metrics - In general it's the logical > configuration view vs. the actual runtime state of a domain. Where i'm > not sure it makes much sense trying to combine them into one single view > (well let's say one which can be retrieved with recursive=true). > Yes, this is what lead to the idea below of "runtime resources" where a recursive=true flag wouldn't traverse into the child resource. Logically, at the DC level host=hostA is a "runtime resource" and at the HC level server=server1 is a "runtime resource".

> First from a tooling perspective i don't think you want to have the > metrics from possibly 100 servers together with the configuration (where > you rather either pick one of them). Also if we allow system property > replacement for standalone the actual runtime state is again different > from the configuration. So having the runtime information as i.e. a > separate operation sounds more interesting to me. This should also make > the "cost" of the operation more obvious. Obviously we could create some > convenience operations which just get both. > So are you ok with 1) and 2) above, but don't want a read-resource call to pull in metrics, unless perhaps a flag is set?

>> 2) How to ensure the "storage" and "access-type" fields are correctly >> set? Likely replace/overload ModelNodeRegistration's >> >> void registerReadOnlyAttribute(String attributeName, OperationHandler >> readHandler); >> void registerReadWriteAttribute(String attributeName, OperationHandler >> readHandler, OperationHandler writeHandler); >> >> with >> >> void registerReadOnlyAttribute(String attributeName, OperationHandler >> readHandler, Storage storage); >> void registerReadWriteAttribute(String attributeName, OperationHandler >> readHandler, OperationHandler writeHandler, Storage storage); >> void registerMetric(String attributeName, OperationHandler readHandler); >> > > Having a metric handler per attribute-name / metric-name seems too much. > I'd rather have an optional attribute-name, so the metric handler can > either filter or just get one metric. > A simple "void registerMetricHandler(OperationHandler handler)" doesn't give the controller any information about what's a metric and what isn't. The only way to find out is to invoke the DescriptionProvider for the resource and read the metadata. And hope the dev did it right.

If it's important to just register a single handler per-resource, then we'll need to register some sort of MetricHandler interface: public interface MetricHandler { Set<String> getHandledMetricNames(); Cancellable execute(NewOperationContext context, String metricName, ResultHandler resultHandler); }