[wildfly-dev] Metrics & runtime attribute registration

[Brian Stansberry]

I agree it's better to be uniform. There are a few things we need to 
resolve though before making this the policy.

1) An attribute description includes the 'nillable' field, which 
indicates whether a client can expect ModelType.UNDEFINED as the 
attribute value. With this change, every metric may return 
ModelType.UNDEFINED, since there cannot be a value if the process is in 
--admin-only mode. I see two options:

a) For every metric we automatically record 'true' as the value for 
'nillable'. The downside here is there is no way for a client to know if 
ModelType.UNDEFINED is a valid value when the process isn't in 
--admin-only.

b) We leave things as is, but clients can check if the 'access-type' 
field has a value of 'metric' and use that to understand that the value 
may sometimes be ModelType.UNDEFINED regardless of what 'nillable' says.

As I typed this I've formed a strong preference for a). To me b) is voodoo.


2) We reuse the same ResourceDefinition class on both a HostController 
and on a server. The use on a HostController is to define the domain 
level resource (e.g. /profile=*/subsystem=foo).

When a normal extension is running on a host controller, it *should not* 
register metrics.[1] Just because we reuse a ResourceDefinition class 
doesn't mean the resource is the same, and a /profile=*/subsystem=foo 
resource is not the same as /subsystem=foo on a server. It's just a 
chunk of config and does not have metrics.

The ExtensionContext has methods that can be used by extensions to 
figure out this kind of state stuff. As part of implementing this policy 
we'd change the behavior of the isRuntimeOnlyRegistrationValid() method 
so hopefully this kind of change would be transparent to existing 
extensions.

3) There a difference between registering a resource's definition and 
actually handling a request for the metric. I expect most metric read 
handlers are not written to function properly if the underlying services 
are not there. Hopefully most will "just work" based on extending some 
of our base handler classes, which will bypass execution in an 
--admin-only server. But we should expect that this change will result 
in some breakage that will have to be cleaned up as part of the work.

Cheers,
Brian


[1] Unless it's a host extension; which we can get into if anyone cares.

On 7/14/15 6:13 AM, Tristan Tarrant wrote:
> Yes, always is best as it provides a more uniform environment for tests too.
>
> Tristan
>
> On 14/07/2015 09:00, Heiko Braun wrote:
>> +1 for ‘awalys'
>>
>>
>>
>>> On 13 Jul 2015, at 23:26, Tomaž Cerar <tomaz.cerar at gmail.com
>>> <mailto:tomaz.cerar at gmail.com>> wrote:
>>>
>>> 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.
>>
>>
>>
>> _______________________________________________
>> 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