Re: [jboss-as7-dev] Attributes, metrics, additional descriptive information for such
Please see my comments inline.
On Feb 2, 2011, at 4:03 AM, Brian Stansberry wrote:
>
> 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.
Yes, I can see that case: RHQ. Furthermore I believe, that metrics follow different rules
then the domain configuration data.
They will be requested more frequently and are subject to be maintained by each subsystem,
not the domain controller.
It the subsystem that updates the metrics, but the domain controller that modifies the
configuration.
This also means that metrics will easily cause thread synchronization/locking issues when
being requested from an external component (external to the subsystem). In a previous
email I tried to get to this point, when asking about "pull vs. push" of runtime
data.
Does that make sense?
> 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
How do we identify metrics in this case?