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

[Heiko Braun]

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?