9:03 p.m.
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