10:58 p.m.
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(a)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&g...
>>>
>>> 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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat