Re: [wildfly-dev] Configuration of statistics gathering

Should the management console changes also be done as part of this? Or should separate jiras be created for updating the management console to use the "statistics-enabled" attribute name? On 12/16/2013 03:12 PM, Brian Stansberry wrote: > I've sent in a PR [1] that makes the changes I described for the > messaging, transactions, resource-adapters and infinispan subsystems, > one commit per subsystems. If the respective leads could have a look I'd > appreciate it. > > Those are the WF subsystems that have a specific attribute for this. JPA > has an attribute, but it's part of jipijapa, so that will need to be > corrected there [2]. JGroups has a particular property key for this > instead of an attribute, and there is already a JIRA for updating that > [3]. > > [1] https://github.com/wildfly/wildfly/pull/5609 > [2] https://issues.jboss.org/browse/JIPI-28 > [3] https://issues.jboss.org/browse/WFLY-2453 > > On 12/12/13 11:38 AM, 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. >> >> >> [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. >>> >> >> > >