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

[Emanuel Muckenhuber]

On 01/26/2011 03:19 PM, Brian Stansberry wrote:
> 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".
>

Ok, great.

>> 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?
>

I was more thinking of having them separate - at least i'd also like to 
get the runtime state separate from the configuration. So i'm not sure 
if they should be mixed with the configuration attributes at the same 
level and 2 flags sounds a bit weird. Also if you have like 
max-thread-pool-size=${max.thread.pool.size:10} - then you'd need a 
separate attribute with actual-thread-max-pool-size?

>>> 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.
>

Hmm, another reason why it would make sense to have them separate ;)

> 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);
>
> }

One thing which i think is interesting about having one metricHandler 
per "runtime resource" is that you have to call execute only once to get 
all the metrics rather than running execute N times for each name.