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 [1] https://github.com/wildfly/wildfly/pull/5415 [2] https://issues.jboss.org/browse/WFLY-2415 _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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?

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.

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.

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?

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.

> Why do you single me out, dude ;) You're the guy who argued for 'true'!

> 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. > My previous post wasn't meant to propose making this configurable in deployment descriptors (although maybe that's a good idea; I haven't really thought about it.) I mentioned the PU descriptor just because I was using JPA as an example and IIRC config in the DD is part of that particular example. Hibernate lets the user enable/disable statistics via a property in persistence.xml.

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. > Ok. > 3) Any new stuff people do (e.g. [1], [2]), please use "statistics-enabled". > Agreed. > 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. Best regards, Jesper _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

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

Good point. HAL is a separate project, so console updates need their own issue. I filed https://issues.jboss.org/browse/HAL-330. I'm not sure how Harald/Heiko will want to deal with the fact that this overall change will involve separate server-side changes coming in over time. I suggest starting with comments on HAL-330. On 12/16/13 2:50 PM, Scott Marlow wrote: > 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. >>>> >>> >>> >> >> >

This change for the IronJacamar controlled resources is in the same category as turning off developer mode for the web container.

Should all project leads submit pull requests that optimizes their subsystems against production use ? Consider this my official -1. Best regards, Jesper _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

AFAICT, the resource-adapter commit did nothing to change any default. So if it was true, it still is true.

Looking at it, I see the existing code doesn't state the default as part of the metadata, so the user doesn't know. That should be fixed.

Earlier in this thread I threw out a suggestion for a subsystem-level attribute that could serve as a default and could easily have a different value in our standard configs for EAP vs WF. If anyone has a better idea, I'd love hear it. If not, patches would be nice if someone wants to do that.

Please explain how the resource-adapter commit relates to your concerns.

I'm ok with the code changes. HOWEVER, the default value should be true. WildFly is a server which aims at ease for developers, so all default settings should reflect that. So, using a default value of false in this case is wrong.

From: "Jason Greene" <jason.greene(a)redhat.com&gt; To: "Jesper Pedersen" <jesper.pedersen(a)jboss.org&gt; Cc: wildfly-dev(a)lists.jboss.org Sent: Tuesday, December 17, 2013 1:14:18 PM Subject: Re: [wildfly-dev] Configuration of statistics gathering On Dec 17, 2013, at 2:06 PM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: > > On Dec 17, 2013, at 2:09 AM, Jesper Pedersen > <jesper.pedersen(a)jboss.org&gt; wrote: > >> >> I'm ok with the code changes. HOWEVER, the default value should be >> true. >> >> WildFly is a server which aims at ease for developers, so all >> default >> settings should reflect that. So, using a default value of false >> in this >> case is wrong. > > I disagree that statistics are a developer concern. IMO they are > more of a production debugging feature and you only need them if > you plan to look at them. Otherwise it’s really just a bottleneck. Slight tangent. We should test out LongAdder for connection pool stats at some point. It should make a significant perf difference.

-- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev