[wildfly-dev] Configuration of statistics gathering

[Brian Stansberry]

On 12/12/13 3:15 PM, Scott Marlow wrote:
> On 12/12/2013 12:38 PM, Brian Stansberry wrote:
>> Thanks, everyone, for the input on this.
>>
>> I'd like to do the following about getting configuration of these
>> consistent for WF 8.0:
>>
>> 1) For all resources that currently expose an attribute to
>> enable/disable statistics, I'll add an attribute that will be named
>> "statistics-enabled". Why that?
>>
>> a) it's an attribute, so it's name should reflect a state, not an action
>> like, for example, "enable-statistics"
>> b) simply using "statistics" is shorter, but in some places that key is
>> used as a child type (e.g. statistics=pool) and a resource can't have a
>> child type and an attribute with the same name.
>>
>> 2) For compatibility, the existing attribute will be retained as an
>> alias to the new one. I'll add deprecation metadata. I'll also set up
>> the appropriate transformation stuff for mixed domain usage.
>>
>> 3) Any new stuff people do (e.g. [1], [2]), please use
>> "statistics-enabled".
>>
>> 4) My intent is to make the default values for these attributes be
>> "false". I won't change any default though unless the relative compoent
>> lead has indicated agreement in this thread or elsewhere.
>>
>> But, if you disagree with "false" as the default, please let's use this
>> thread to sort that out, get input from the performance team, etc, so we
>> can have at least a clear understanding of why some uses have 'true'.
>>
>> Jesper, ^^^. ;-)
>>
>>
>> That's for WF 8. For the next release I recommend that we also create
>> subsystem-level attributes to hold the default value for the several
>> cases where this setting is only configurable on a per-deployment level.
>> An example would be the jpa subsystem could have a statistics-enabled
>> attribute that drives the setting for all persistence units unless the
>> PU descriptor overrides or the admin overrides using the existing
>> per-deployment attribute. Besides being an aid to usability, having an
>> attribute that ends up in the persistent configuration will also help
>> deal with issues where, for example, the desired default for WildFly is
>> different than the desired default for some future EAP release. The
>> standard configs for the EAP release can just use a different value.
>
> Should the deployment level settings always take precedence?  If yes,
> then deployments that specify a statistics setting (e.g. persistence.xml
> includes a hint to set statistics to some state), are not be controlled
> by the subsystem level setting.  Having deployment settings override the
> subsystem settings sounds fine to me but I wanted to point out that we
> could let the subsystem settings override the deployment settings.
>

True.

> I wonder if "statistics-enabled" should have three states, so that the
> subsystem level settings always overrides the deployment level?  For the
> JPA case (with Hibernate):
>
> true - statistics are enabled (even if the persistence.xml includes a
> hint to disable statistics).
>
> false - statistics are disabled (even if the persistence.xml includes a
> hint to enable statistics).
>
> ignore - statistics are determined by property hints in the persistence
> unit (in persistence.xml).
>

In the end there would have to be a default though. That is, if there is 
no deployment-level setting, "ignore" would have to be statically 
defined as meaning true or false.

> IMO, I like having the deployment settings override the subsystem level
> settings.  I would find it frustrating if setting a deployment level
> setting is ignored (one of the challenges of allowing multiple levels to
> set the same property).
>

I prefer deployments overriding too. I think the opposite would be 
pretty unintiutive, and requires complex stuff like the "ignore" value. 
In general, things work in our management on a 
more-specific-overrides-less-specific basis (e.g. system property 
settings at various levels in the domain/host config) and I think it's 
good to be consistent about that. Also, we have another mechanism for 
allowing admins to override the settings in their deployments: 
deployment overlays.

Do we have other cases where subsystem configs override some aspect of 
deployment config?

Side note on JPA: a subsystem-level setting presumes that the different 
providers have some mechanism for enabling/disabling statistics. If they 
don't a subsystem level setting becomes meaningless. Which isn't the end 
of the world, since our standard provider support this.


>>
>>
>> [1] https://issues.jboss.org/browse/JBWS-3733
>> [2] https://issues.jboss.org/browse/WFLY-2453
>>
>> On 11/6/13 10:26 AM, Brian Stansberry wrote:
>>> I'd like to get some info from the component leads responsible for WF
>>> subsystems.
>>>
>>> 1) What statistical data does your subsystem capture (including the
>>> underlying libraries it integrates).
>>>
>>> 2) What configuration options do you support for enabling/disabling
>>> statistics gathering. What's the resource address and attribute name of
>>> the config option?
>>>
>>> 3) Is the statistic gathering enabled by default?
>>>
>>> Paul Ferraro's pull request [1] fixing JIRA [2] prompts this question,
>>> although it's long overdue. WF should be consistent about how we handle
>>> configuration of statistics gathering, so I'd like to take the
>>> opportunity of Paul's PR to move in that direction.
>>>
>>> Thanks for your help.
>>>
>>
>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat