3:15 p.m.
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.
>