Re: [jboss-as7-dev] Attributes, metrics, additional descriptive information for such
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.