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

[Emanuel Muckenhuber]

On 02/03/2011 11:12 AM, Heiko Braun wrote:
> On Feb 2, 2011, at 4:03 AM, Brian Stansberry wrote:
>>
>> 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?
>

In the end you would have three ways (operations) to retrieve a metric:

1) "read-resource" with "include-runtime=true"
- this gives you the the configuration incl. metrics
2) "read-attribute"
- reads a single attribute value
3) "query-metrics" (TBD)
- retrieves the metrics only for a resource

In the domain case you would need to use a operation address like: 
host=*,server*,subsystem=web,connector=web - to actually query the 
runtime state.

The reason why metrics look more like an attribute is that a potential 
JMX mapping would be easier. However they have to explicitly register 
handlers to retrieve the value and therefore not part of the 
configuration model - the operations just provide an aggregated view.

For now the metrics have to pulled, we are thinking of a push model for 
the future.

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

The "type" of an attribute is part of the model description.