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

[Brian Stansberry]

I thought I'd sent this a couple days ago, but apparently not. :(

On 1/27/11 1:54 PM, Heiko Braun wrote:
>
> On Jan 26, 2011, at 4:18 PM, Emanuel Muckenhuber wrote:
>
>>> 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.
>
>
> IMO the separation makes sense. For use cases that don't require metrics,
> that data should not be send over the wire. I would prefer a custom operation opposed to
> another operation attribute switch, like "includeMetrics=false".
>

Why?

We were going with a "include-runtime" flag on the read-resource 
operation, with a default of "false". Do you see a case where people 
want to query all the metrics for a resource but not the configuration 
values? I'd think the norm would be just show me the configuration data, 
with runtime information retrieved individually.

> On the API level this separation highlights that metrics run under different performance considerations
> and different semantics apply in general. It should not be intermingled with config data.
> Anything we build atop of that (caching, aggregation, etc) would clearly benefit from a distinction build into the API
> right from the beginning.
>
> But to make sure I understand you correctly:
>
> - Does this means you have a custom operation to retrieve the metrics per resource?
>    (probably yes)
>

No; but we could consider one if retrieving all non-configuration values 
for a resource is an expected use-case.

Jason, would this cause a problem for how you are mapping requests to 
the HTTP interface?

> - Could metrics also be retrieved when reading the configuration?
>    I.e. separate payload element, but still one request?
>

Yes and no. Yes the metrics can be retrieved along with configuration, 
via read-resource with include-runtime=true. But no, they don't come as 
a separate payload element

Right now the actual model data that comes from a read-resource has a 
flat structure, with no intermediate level to group certain "types" of 
data. So, if the resource has a configuration attribute max-size, a 
metric current-size, and a child resource of type "foo" the data would 
conceptually look like:

+
++ max-size=10
++ current-size=5
++ foo
++++ foo-1
++++++ bar="XYZ"

and not:

+
++ attributes
++++ max-size=10
++++ current-size=5
++ children
++++ foo
++++++ foo-1
++++++++ bar="XYZ"

Basically this assumes that the read-resource-description data would be 
used to differentiate the types of data, if necessary. Let me know if 
this is a problem.


> - Although there is one handler per resource, will it be possible to retrieve just a single metric value?
>

Yes, any attribute (whether configuration or metric) can be read 
individually. Now it's a simple read-attribute name="xxx".

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat