[wildfly-dev] Metrics & runtime attribute registration

[Brian Stansberry]

The registry already has data to distinguish these; they are registered 
as metrics.

Heiko Braun had a good point today though. The issues we're discussing 
here are not limited to --admin-only. There are many metrics that can be 
disabled by setting some "statistics-enabled" attribute somewhere to 
false. Those metrics will still be registered though; they'll just not 
have a typical value. Since we have to deal with that case anyway, I 
don't see much value in hiding the attributes in --admin-only.

Jason and I had a long chat in the WildFly hipchat room today though and 
for many metrics, returning null is silly. For example counters, where 0 
is a perfectly reasonable value. Which further argues against hiding the 
metrics.

If there are 3 categories of metrics:

1) Those with a natural 'initial value' like 0 to use if there is no runtime
2) Those that intuitively might have a null value, like a 
'last-request-time' for some handler that's never handled a request
3) Those that don't naturally have a natural 'initial value' and also 
aren't intuitively nillable (say a "free-space" metric)

How many are in the 3rd category and how big of a problem is it to 
return null anyway?

On 7/14/15 3:33 PM, Kabir Khan wrote:
> Could these be added to the registry with some special flag?
> My vague thought is that they would then be ‘hidden’ in admin-only mode, unless r-r-d is called with some new parameter.
> In normal mode they are visible.
>
>> On 14 Jul 2015, at 20:59, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> One thing that came up yesterday is generating code based on the model
>> description. If you're doing that you want as much data as possible. You
>> don't want to bring up an -admin-only process (say one embedded in the
>> code generation tool) just to read and generate, and then find out you
>> missed a bunch of attributes.
>>
>> On 7/14/15 1:52 PM, James R. Perkins wrote:
>>> If the attribute is going to be undefined what is the benefit of having
>>> it in the model? If the tooling is looking for an attribute that doesn't
>>> exist wouldn't they just check for the existence with ModelNode.has()?
>>>
>>> I don't write any tooling so maybe I'm off :) I just don't see the
>>> benefit of adding an attribute that will always be UNDEFINED though.
>>>
>>> On 07/13/2015 02:26 PM, Tomaž Cerar wrote:
>>>> Hey guys,
>>>>
>>>> We had interesting discussion with Brian on
>>>> <https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986>https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986
>>>>
>>>> about how we register runtime/metric attribute on resources.
>>>>
>>>> There are many cases where subsystems only register attributes /
>>>> resources only when server is booting into normal mode.
>>>> but if it server is booted only to "admin mode" all that
>>>> runtime/metrics attributes are not registered and as such not seen in
>>>> the model.
>>>>
>>>> Registering runtime attributes only in normal mode can cause that
>>>> results of :read-resource-description/read-resource
>>>> wouldn't return attributes that are on resources if server is started
>>>> in admin mode or even CLI standalone.
>>>> Our metadata already provides information if attributes is
>>>> runtime/metric/configuration.
>>>>
>>>> This can cause problems for tooling that relies on output of those two
>>>> operations.
>>>>
>>>> Looking at current state of the code, we do use both ways of
>>>> registering attributes either conditionally or always.
>>>> This probably originates from times where there was no good api/way to
>>>> mark attribute/resource as runtime.
>>>>
>>>> I am personally am in favor of always registering runtime attributes
>>>> as this makes sure that user isn't surprised by some extra/missing
>>>> attributes based on fact how it is starting the server.
>>>>
>>>>
>>>> What do you guys think? Should we always register it or have it
>>>> conditionally?
>>>>
>>>> --
>>>> tomaz
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> --
>>> James R. Perkins
>>> JBoss by Red Hat
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat