On 12/12/2013 12:38 PM, Brian Stansberry wrote:
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"
Ok with that.
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.
Yeah, lets not change this.
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. , ), please use
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'.
IronJacamar uses statistics internally in order to display run-time
information of the pools.
IronJacamar 1.1.2+ has a change which will allow to turn-off statistics,
but that results in nothing is displayed to the users in that case.
If we turn-off statistics by default we will have to be careful on what
to communicate to the users, since they will expect see basic
information out of the box. Maybe IronJacamar can display more
information than the core pool settings, but requires further investigation.
I think in order to turn it off we need proof that there is a huge
benefit for standard work loads. In the end we are talking about an
extra section in the guide that explains turning off statistics will
increase performance. Nothing new there. Or ship a "performance" profile.
Just so we are on the same page, the IronJacamar statistics is done by 2
x System.currentTimeMillis() + a call to Atomic(Long|Integer|...) - let
the flame war begin :) As always, patches welcome.
Jesper, ^^^. ;-)
Why do you single me out, dude ;)
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.
Sounds good, although having it as an option in each deployment
descriptor for each component type maybe overkill. I think an option in
wildfly.xml would be enough, and then override through
statistics-enabled via CLI.