[wildfly-dev] Configuration of statistics gathering

[Scott Marlow]

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.

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).

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).

>
>
> [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.
>>
>
>