Odg: Odg: disable statistic archival

[Mario Kevo]

Hi Kirk,

In DistributionConfig we have setStatisticArchiveFile() which is implemented in 
DistributionConfigImpl  and RuntimeDistributionConfigImpl. There you can see 
when it read properties from properties file if statistic-archive-file is null 
then it writes an empty file:

public void setStatisticArchiveFile(File value) {
   if (value == null) {
value = new File("");
  }
  statisticArchiveFile = value;
}

But in the case we change it from gfsh with alter runtime command it go through 
all parameters(which can be changed by this command) and check if it is 
different than null, in the case it is different than null and not empty it 
updates properties file. If we set --statistic-archive-file="" it will see that 
it is empty and then we got "Please provide a relevant parameter(s)" as it 
reads like it has no parameters.

BR,
Mario

Šalje: Kirk Lund 
Poslano: 23. siječnja 2020. 18:55
Prima: geode 
Predmet: Re: Odg: disable statistic archival

I hadn't thought of this usage before, but it makes sense. If you want
stats showing up on MBeans and/or in Micrometer, then setting
--statistic-archive-file="" is probably the correct way to do it. It's
possible that ServerLauncher or something deeper is
setting --statistic-archive-file to a non-empty value if it's empty. I
think you probably need to find that code and then review it to see how it
needs to change. If you find it, point me at it and I'll help review it.

On Wed, Jan 22, 2020 at 11:36 PM Mario Kevo  wrote:

> @Kirk, in case we change --enable-statistic(this
> flag refer to STATISTIC_SAMPLING_ENABLED ) to false we lose some metrics in
> gfsh and pulse.
> What if we want to keep statistic on, but not archive it to file.
> I don't see now how to disable archiving statistics to file, but keep
> statistics in gfsh and pulse.
>
> Yes, the user guide could be clearer.
>
>
> 
> Šalje: Kirk Lund 
> Poslano: 22. siječnja 2020. 20:44
> Prima: geode 
> Predmet: Re: disable statistic archival
>
> Dave, In your list, I think "enable-statistics" should be
> "enable-time-statistics". But, yes you're right!
>
> On Wed, Jan 22, 2020 at 9:46 AM Dave Barnes  wrote:
>
> > I'm getting the impression that the user guide could be clearer with
> regard
> > to the interactions between
> >
> >- enable-statistics
> >- statistic-sampling-enabled
> >- statistic-archive-file
> >
> >
> >
> > On Wed, Jan 22, 2020 at 9:30 AM Kirk Lund  wrote:
> >
> > > Try setting STATISTIC_SAMPLING_ENABLED to false to disable statistic
> > > sampling.
> > >
> > > I think we should delete "An empty string (default) disables statistic
> > > archival." from the javadocs for STATISTIC_ARCHIVE_FILE to avoid
> > confusion
> > > and redundancy with STATISTIC_SAMPLING_ENABLED.
> > >
> > > See below for the javadocs on both properties.
> > >
> > >   /**
> > >* The static String definition of the
> "statistic-archive-file"
> > > property  > >* name="statistic-archive-file"/a>
> > >* 
> > >* Description: The file that statistic samples are written
> to.
> > An
> > > empty string (default)
> > >* disables statistic archival.
> > >* 
> > >* Default: ""
> > >*/
> > >   String STATISTIC_ARCHIVE_FILE = "statistic-archive-file";
> > >
> > >   /**
> > >* The static String definition of the
> > > "statistic-sampling-enabled" property  > >* name="statistic-sampling-enabled"/a>
> > >* 
> > >* Description: "true" causes the statistics to be sampled
> > > periodically and operating
> > >* system statistics to be fetched each time a sample is taken.
> "false"
> > > disables sampling which
> > >* also disables operating system statistic collection. Non OS
> > statistics
> > > will still be recorded
> > >* in memory and can be viewed by administration tools. However,
> charts
> > > will show no activity and
> > >* no statistics will be archived while sampling is disabled.
> Starting
> > in
> > > 7.0 the default value
> > >* has been changed to true. If statistic sampling is disabled it
> will
> > > also cause various metrics
> > >* seen in gfsh and pulse to always be zero.
> > >* 
> > >* Default: "true"
> > >* 
> > >* Allowed values: true|false
> > >*/
> > >   String STATISTIC_SAMPLING_ENABLED = "statistic-sampling-enabled";
> > >
> > > On Tue, Jan 21, 2020 at 1:06 AM Mario Kevo 
> wrote:
> > >
> > > > Hi,
> > > >
> > > > We are trying to disable archiving statistic in the file by providing
> > > > empty string to --statistic-archive-file. This option doesn't work.
> > > > From the documentation it should work:
> > > > The file to which the running system member writes statistic samples.
> > For
> > > > example: “StatisticsArchiveFile.gfs”. An empty string disables
> > archiving.
> > > > I opened ticket(GEODE-7714<
> > > > https://issues.apache.org/jira/browse/GEODE-7714>) and try to fix
> it,
> > > but
> > > > without success.
> 

Re: Request for Docker Hub permissions

[Owen Nichols]

You should have access now.

Thanks for stepping up as apprentice release manager with Ernie, and perhaps as 
a release manager in the future.

> On Jan 21, 2020, at 2:37 PM, Dave Barnes  wrote:
> 
> Please grant me permission to upload Apache Geode artifacts to Docker hub
> using my ID: dbarnes97. Thanks!

Re: Old geode-benchmark PRs

[Jacob Barrett]

Why not just leave the PR open then?

> On Jan 23, 2020, at 9:52 AM, Robert Houghton  wrote:
> 
> @Alberto I like this idea. The link between Jira and the GitHub PR will be
> a nice breadcrumb to follow going forward as well, assuming the PRs are
> correctly labeled for cross-linking to occur.
> 
> 
> On Thu, Jan 23, 2020 at 8:05 AM Alberto Bustamante Reyes
>  wrote:
> 
>> What about closing the PRs and creating a Jira ticket (or tickets) for the
>> review and update of the code?
>> If someone finds time to spend on benchmarks, at least he/she will find
>> the tickets in Jira.
>> 
>> 
>> 
>> De: Donal Evans 
>> Enviado: jueves, 23 de enero de 2020 16:45
>> Para: dev@geode.apache.org 
>> Asunto: Re: Old geode-benchmark PRs
>> 
>> @Alexander, I haven't looked at them in months and they never received any
>> formal review on GitHub, so it's hard to know for sure if they're ready to
>> merge or not, but as Jake said, they probably need some massaging to get
>> the resource usage just right and minimize variance. If at this point
>> there's no-one who knows enough about tuning benchmarks with the time to
>> look at them, then it seems unlikely that they'll get merged any time soon.
>> 
>> On Thu, Jan 23, 2020 at 6:42 AM Alexander Murmann 
>> wrote:
>> 
>>> Donal, are you still looking at these? If they aren't ready to merge and
>>> not being worked on, should they be closed?
>>> 
>>> On Wed, Jan 22, 2020 at 3:32 PM Donal Evans  wrote:
>>> 
 Two of those PRs are mine, so perhaps I can give a bit of context for
 people who might look at them. The oldest of the two, "Feature/Add
>>> PdxType
 benchmark and additional framework flexibility" was an attempt to
>>> quantify
 and maintain the improvement in performance for PdxType creation when
>>> large
 numbers of PdxTypes already exist, and to allow the passing of
>> additional
 system properties to the VMs hosting the servers in order to change the
>>> log
 level and prevent the benchmark measuring how long it takes to log
>>> PdxType
 creation rather than actual time taken to create new PdxTypes. This PR
>>> has
 been open for a very long time, so it's possible that the changes
>>> regarding
 passing additional system properties to the VMs are now outdated or
 unnecessary, but the actual benchmarks themselves still have some
>> value.
 
 The second PR, "Added benchmarks for aggregate functions" contains 16
>> new
 benchmarks related to aggregate OQL queries, (8 each for Partitioned
>> and
 Replicated regions), which were added following work in that area by
>> the
 Commons team. The build is currently marked as failing, but this is due
>>> to
 a timeout rather than an actual build failure, as the number of
>>> benchmarks
 added increased the total time to build beyond the currently configured
 timeout. Adding such a large number of additional benchmarks will
>>> probably
 also noticeably increase the time it takes benchmarks to run, which
>> bears
 consideration.
 
 I hope this helps shed some light for people who may look over those
>> PRs.
 
 On Wed, Jan 22, 2020 at 11:36 AM Dan Smith  wrote:
 
> Hi,
> 
> I noticed we have some old outstanding PRs for the geode-benchmarks
> project. Are any of these things we want to merge or should we close
>>> them
> out?
> 
> https://github.com/apache/geode-benchmarks/pulls
> 
> -Dan
> 
 
>>> 
>> 

Re: Odg: disable statistic archival

[Kirk Lund]

I hadn't thought of this usage before, but it makes sense. If you want
stats showing up on MBeans and/or in Micrometer, then setting
--statistic-archive-file="" is probably the correct way to do it. It's
possible that ServerLauncher or something deeper is
setting --statistic-archive-file to a non-empty value if it's empty. I
think you probably need to find that code and then review it to see how it
needs to change. If you find it, point me at it and I'll help review it.

On Wed, Jan 22, 2020 at 11:36 PM Mario Kevo  wrote:

> @Kirk, in case we change --enable-statistic(this
> flag refer to STATISTIC_SAMPLING_ENABLED ) to false we lose some metrics in
> gfsh and pulse.
> What if we want to keep statistic on, but not archive it to file.
> I don't see now how to disable archiving statistics to file, but keep
> statistics in gfsh and pulse.
>
> Yes, the user guide could be clearer.
>
>
> 
> Šalje: Kirk Lund 
> Poslano: 22. siječnja 2020. 20:44
> Prima: geode 
> Predmet: Re: disable statistic archival
>
> Dave, In your list, I think "enable-statistics" should be
> "enable-time-statistics". But, yes you're right!
>
> On Wed, Jan 22, 2020 at 9:46 AM Dave Barnes  wrote:
>
> > I'm getting the impression that the user guide could be clearer with
> regard
> > to the interactions between
> >
> >- enable-statistics
> >- statistic-sampling-enabled
> >- statistic-archive-file
> >
> >
> >
> > On Wed, Jan 22, 2020 at 9:30 AM Kirk Lund  wrote:
> >
> > > Try setting STATISTIC_SAMPLING_ENABLED to false to disable statistic
> > > sampling.
> > >
> > > I think we should delete "An empty string (default) disables statistic
> > > archival." from the javadocs for STATISTIC_ARCHIVE_FILE to avoid
> > confusion
> > > and redundancy with STATISTIC_SAMPLING_ENABLED.
> > >
> > > See below for the javadocs on both properties.
> > >
> > >   /**
> > >* The static String definition of the
> "statistic-archive-file"
> > > property  > >* name="statistic-archive-file"/a>
> > >* 
> > >* Description: The file that statistic samples are written
> to.
> > An
> > > empty string (default)
> > >* disables statistic archival.
> > >* 
> > >* Default: ""
> > >*/
> > >   String STATISTIC_ARCHIVE_FILE = "statistic-archive-file";
> > >
> > >   /**
> > >* The static String definition of the
> > > "statistic-sampling-enabled" property  > >* name="statistic-sampling-enabled"/a>
> > >* 
> > >* Description: "true" causes the statistics to be sampled
> > > periodically and operating
> > >* system statistics to be fetched each time a sample is taken.
> "false"
> > > disables sampling which
> > >* also disables operating system statistic collection. Non OS
> > statistics
> > > will still be recorded
> > >* in memory and can be viewed by administration tools. However,
> charts
> > > will show no activity and
> > >* no statistics will be archived while sampling is disabled.
> Starting
> > in
> > > 7.0 the default value
> > >* has been changed to true. If statistic sampling is disabled it
> will
> > > also cause various metrics
> > >* seen in gfsh and pulse to always be zero.
> > >* 
> > >* Default: "true"
> > >* 
> > >* Allowed values: true|false
> > >*/
> > >   String STATISTIC_SAMPLING_ENABLED = "statistic-sampling-enabled";
> > >
> > > On Tue, Jan 21, 2020 at 1:06 AM Mario Kevo 
> wrote:
> > >
> > > > Hi,
> > > >
> > > > We are trying to disable archiving statistic in the file by providing
> > > > empty string to --statistic-archive-file. This option doesn't work.
> > > > From the documentation it should work:
> > > > The file to which the running system member writes statistic samples.
> > For
> > > > example: “StatisticsArchiveFile.gfs”. An empty string disables
> > archiving.
> > > > I opened ticket(GEODE-7714<
> > > > https://issues.apache.org/jira/browse/GEODE-7714>) and try to fix
> it,
> > > but
> > > > without success.
> > > >
> > > > As alter runtime command update properties and cache, it checks if
> any
> > of
> > > > these parameters change, but if we set this property to an empty
> string
> > > it
> > > > failed with message
> > > > Please provide a relevant parameter(s).
> > > > We can change for this parameter that it can be an empty string but
> how
> > > > this command works, it goes over all parameters and checks if it is
> > > > changed. In that case if we provide something like
> > > > alter runtime --member=server it will be successiful but shouldn't as
> > we
> > > > didn't provide any parameter.
> > > >
> > > > So the proposal is that we need to add a new parameter called
> > > > --statistic-archiving-enabled  which can be true or false. In case it
> > is
> > > > true we need to provide also --statistic-archive-file.
> > > >
> > > > Any thougths?
> > > >
> > > > BR,
> > > > Mario
> > > >
> > > >
> > >
> >
>

Re: Old geode-benchmark PRs

[Robert Houghton]

@Alberto I like this idea. The link between Jira and the GitHub PR will be
a nice breadcrumb to follow going forward as well, assuming the PRs are
correctly labeled for cross-linking to occur.


On Thu, Jan 23, 2020 at 8:05 AM Alberto Bustamante Reyes
 wrote:

> What about closing the PRs and creating a Jira ticket (or tickets) for the
> review and update of the code?
> If someone finds time to spend on benchmarks, at least he/she will find
> the tickets in Jira.
>
>
> 
> De: Donal Evans 
> Enviado: jueves, 23 de enero de 2020 16:45
> Para: dev@geode.apache.org 
> Asunto: Re: Old geode-benchmark PRs
>
> @Alexander, I haven't looked at them in months and they never received any
> formal review on GitHub, so it's hard to know for sure if they're ready to
> merge or not, but as Jake said, they probably need some massaging to get
> the resource usage just right and minimize variance. If at this point
> there's no-one who knows enough about tuning benchmarks with the time to
> look at them, then it seems unlikely that they'll get merged any time soon.
>
> On Thu, Jan 23, 2020 at 6:42 AM Alexander Murmann 
> wrote:
>
> > Donal, are you still looking at these? If they aren't ready to merge and
> > not being worked on, should they be closed?
> >
> > On Wed, Jan 22, 2020 at 3:32 PM Donal Evans  wrote:
> >
> > > Two of those PRs are mine, so perhaps I can give a bit of context for
> > > people who might look at them. The oldest of the two, "Feature/Add
> > PdxType
> > > benchmark and additional framework flexibility" was an attempt to
> > quantify
> > > and maintain the improvement in performance for PdxType creation when
> > large
> > > numbers of PdxTypes already exist, and to allow the passing of
> additional
> > > system properties to the VMs hosting the servers in order to change the
> > log
> > > level and prevent the benchmark measuring how long it takes to log
> > PdxType
> > > creation rather than actual time taken to create new PdxTypes. This PR
> > has
> > > been open for a very long time, so it's possible that the changes
> > regarding
> > > passing additional system properties to the VMs are now outdated or
> > > unnecessary, but the actual benchmarks themselves still have some
> value.
> > >
> > > The second PR, "Added benchmarks for aggregate functions" contains 16
> new
> > > benchmarks related to aggregate OQL queries, (8 each for Partitioned
> and
> > > Replicated regions), which were added following work in that area by
> the
> > > Commons team. The build is currently marked as failing, but this is due
> > to
> > > a timeout rather than an actual build failure, as the number of
> > benchmarks
> > > added increased the total time to build beyond the currently configured
> > > timeout. Adding such a large number of additional benchmarks will
> > probably
> > > also noticeably increase the time it takes benchmarks to run, which
> bears
> > > consideration.
> > >
> > > I hope this helps shed some light for people who may look over those
> PRs.
> > >
> > > On Wed, Jan 22, 2020 at 11:36 AM Dan Smith  wrote:
> > >
> > > > Hi,
> > > >
> > > > I noticed we have some old outstanding PRs for the geode-benchmarks
> > > > project. Are any of these things we want to merge or should we close
> > them
> > > > out?
> > > >
> > > > https://github.com/apache/geode-benchmarks/pulls
> > > >
> > > > -Dan
> > > >
> > >
> >
>

RE: Old geode-benchmark PRs

[Alberto Bustamante Reyes]

What about closing the PRs and creating a Jira ticket (or tickets) for the 
review and update of the code?
If someone finds time to spend on benchmarks, at least he/she will find the 
tickets in Jira.



De: Donal Evans 
Enviado: jueves, 23 de enero de 2020 16:45
Para: dev@geode.apache.org 
Asunto: Re: Old geode-benchmark PRs

@Alexander, I haven't looked at them in months and they never received any
formal review on GitHub, so it's hard to know for sure if they're ready to
merge or not, but as Jake said, they probably need some massaging to get
the resource usage just right and minimize variance. If at this point
there's no-one who knows enough about tuning benchmarks with the time to
look at them, then it seems unlikely that they'll get merged any time soon.

On Thu, Jan 23, 2020 at 6:42 AM Alexander Murmann 
wrote:

> Donal, are you still looking at these? If they aren't ready to merge and
> not being worked on, should they be closed?
>
> On Wed, Jan 22, 2020 at 3:32 PM Donal Evans  wrote:
>
> > Two of those PRs are mine, so perhaps I can give a bit of context for
> > people who might look at them. The oldest of the two, "Feature/Add
> PdxType
> > benchmark and additional framework flexibility" was an attempt to
> quantify
> > and maintain the improvement in performance for PdxType creation when
> large
> > numbers of PdxTypes already exist, and to allow the passing of additional
> > system properties to the VMs hosting the servers in order to change the
> log
> > level and prevent the benchmark measuring how long it takes to log
> PdxType
> > creation rather than actual time taken to create new PdxTypes. This PR
> has
> > been open for a very long time, so it's possible that the changes
> regarding
> > passing additional system properties to the VMs are now outdated or
> > unnecessary, but the actual benchmarks themselves still have some value.
> >
> > The second PR, "Added benchmarks for aggregate functions" contains 16 new
> > benchmarks related to aggregate OQL queries, (8 each for Partitioned and
> > Replicated regions), which were added following work in that area by the
> > Commons team. The build is currently marked as failing, but this is due
> to
> > a timeout rather than an actual build failure, as the number of
> benchmarks
> > added increased the total time to build beyond the currently configured
> > timeout. Adding such a large number of additional benchmarks will
> probably
> > also noticeably increase the time it takes benchmarks to run, which bears
> > consideration.
> >
> > I hope this helps shed some light for people who may look over those PRs.
> >
> > On Wed, Jan 22, 2020 at 11:36 AM Dan Smith  wrote:
> >
> > > Hi,
> > >
> > > I noticed we have some old outstanding PRs for the geode-benchmarks
> > > project. Are any of these things we want to merge or should we close
> them
> > > out?
> > >
> > > https://github.com/apache/geode-benchmarks/pulls
> > >
> > > -Dan
> > >
> >
>

Re: Old geode-benchmark PRs

[Donal Evans]

@Alexander, I haven't looked at them in months and they never received any
formal review on GitHub, so it's hard to know for sure if they're ready to
merge or not, but as Jake said, they probably need some massaging to get
the resource usage just right and minimize variance. If at this point
there's no-one who knows enough about tuning benchmarks with the time to
look at them, then it seems unlikely that they'll get merged any time soon.

On Thu, Jan 23, 2020 at 6:42 AM Alexander Murmann 
wrote:

> Donal, are you still looking at these? If they aren't ready to merge and
> not being worked on, should they be closed?
>
> On Wed, Jan 22, 2020 at 3:32 PM Donal Evans  wrote:
>
> > Two of those PRs are mine, so perhaps I can give a bit of context for
> > people who might look at them. The oldest of the two, "Feature/Add
> PdxType
> > benchmark and additional framework flexibility" was an attempt to
> quantify
> > and maintain the improvement in performance for PdxType creation when
> large
> > numbers of PdxTypes already exist, and to allow the passing of additional
> > system properties to the VMs hosting the servers in order to change the
> log
> > level and prevent the benchmark measuring how long it takes to log
> PdxType
> > creation rather than actual time taken to create new PdxTypes. This PR
> has
> > been open for a very long time, so it's possible that the changes
> regarding
> > passing additional system properties to the VMs are now outdated or
> > unnecessary, but the actual benchmarks themselves still have some value.
> >
> > The second PR, "Added benchmarks for aggregate functions" contains 16 new
> > benchmarks related to aggregate OQL queries, (8 each for Partitioned and
> > Replicated regions), which were added following work in that area by the
> > Commons team. The build is currently marked as failing, but this is due
> to
> > a timeout rather than an actual build failure, as the number of
> benchmarks
> > added increased the total time to build beyond the currently configured
> > timeout. Adding such a large number of additional benchmarks will
> probably
> > also noticeably increase the time it takes benchmarks to run, which bears
> > consideration.
> >
> > I hope this helps shed some light for people who may look over those PRs.
> >
> > On Wed, Jan 22, 2020 at 11:36 AM Dan Smith  wrote:
> >
> > > Hi,
> > >
> > > I noticed we have some old outstanding PRs for the geode-benchmarks
> > > project. Are any of these things we want to merge or should we close
> them
> > > out?
> > >
> > > https://github.com/apache/geode-benchmarks/pulls
> > >
> > > -Dan
> > >
> >
>

Re: Old geode-benchmark PRs

[Alexander Murmann]

Donal, are you still looking at these? If they aren't ready to merge and
not being worked on, should they be closed?

On Wed, Jan 22, 2020 at 3:32 PM Donal Evans  wrote:

> Two of those PRs are mine, so perhaps I can give a bit of context for
> people who might look at them. The oldest of the two, "Feature/Add PdxType
> benchmark and additional framework flexibility" was an attempt to quantify
> and maintain the improvement in performance for PdxType creation when large
> numbers of PdxTypes already exist, and to allow the passing of additional
> system properties to the VMs hosting the servers in order to change the log
> level and prevent the benchmark measuring how long it takes to log PdxType
> creation rather than actual time taken to create new PdxTypes. This PR has
> been open for a very long time, so it's possible that the changes regarding
> passing additional system properties to the VMs are now outdated or
> unnecessary, but the actual benchmarks themselves still have some value.
>
> The second PR, "Added benchmarks for aggregate functions" contains 16 new
> benchmarks related to aggregate OQL queries, (8 each for Partitioned and
> Replicated regions), which were added following work in that area by the
> Commons team. The build is currently marked as failing, but this is due to
> a timeout rather than an actual build failure, as the number of benchmarks
> added increased the total time to build beyond the currently configured
> timeout. Adding such a large number of additional benchmarks will probably
> also noticeably increase the time it takes benchmarks to run, which bears
> consideration.
>
> I hope this helps shed some light for people who may look over those PRs.
>
> On Wed, Jan 22, 2020 at 11:36 AM Dan Smith  wrote:
>
> > Hi,
> >
> > I noticed we have some old outstanding PRs for the geode-benchmarks
> > project. Are any of these things we want to merge or should we close them
> > out?
> >
> > https://github.com/apache/geode-benchmarks/pulls
> >
> > -Dan
> >
>

Odg: Odg: disable statistic archival

[Mario Kevo]

Yes, it works with redirecting to /dev/null.
Do we need to document to use this to disable file, or just use this as a 
workaround and continue with adding new flag?


Šalje: Owen Nichols 
Poslano: 23. siječnja 2020. 8:49
Prima: dev@geode.apache.org 
Predmet: Re: Odg: disable statistic archival

Would it work to archive them to file /dev/null

On Wed, Jan 22, 2020 at 11:36 PM Mario Kevo  wrote:

> @Kirk, in case we change --enable-statistic(this
> flag refer to STATISTIC_SAMPLING_ENABLED ) to false we lose some metrics in
> gfsh and pulse.
> What if we want to keep statistic on, but not archive it to file.
> I don't see now how to disable archiving statistics to file, but keep
> statistics in gfsh and pulse.
>
> Yes, the user guide could be clearer.
>
>
> 
> Šalje: Kirk Lund 
> Poslano: 22. siječnja 2020. 20:44
> Prima: geode 
> Predmet: Re: disable statistic archival
>
> Dave, In your list, I think "enable-statistics" should be
> "enable-time-statistics". But, yes you're right!
>
> On Wed, Jan 22, 2020 at 9:46 AM Dave Barnes  wrote:
>
> > I'm getting the impression that the user guide could be clearer with
> regard
> > to the interactions between
> >
> >- enable-statistics
> >- statistic-sampling-enabled
> >- statistic-archive-file
> >
> >
> >
> > On Wed, Jan 22, 2020 at 9:30 AM Kirk Lund  wrote:
> >
> > > Try setting STATISTIC_SAMPLING_ENABLED to false to disable statistic
> > > sampling.
> > >
> > > I think we should delete "An empty string (default) disables statistic
> > > archival." from the javadocs for STATISTIC_ARCHIVE_FILE to avoid
> > confusion
> > > and redundancy with STATISTIC_SAMPLING_ENABLED.
> > >
> > > See below for the javadocs on both properties.
> > >
> > >   /**
> > >* The static String definition of the
> "statistic-archive-file"
> > > property  > >* name="statistic-archive-file"/a>
> > >* 
> > >* Description: The file that statistic samples are written
> to.
> > An
> > > empty string (default)
> > >* disables statistic archival.
> > >* 
> > >* Default: ""
> > >*/
> > >   String STATISTIC_ARCHIVE_FILE = "statistic-archive-file";
> > >
> > >   /**
> > >* The static String definition of the
> > > "statistic-sampling-enabled" property  > >* name="statistic-sampling-enabled"/a>
> > >* 
> > >* Description: "true" causes the statistics to be sampled
> > > periodically and operating
> > >* system statistics to be fetched each time a sample is taken.
> "false"
> > > disables sampling which
> > >* also disables operating system statistic collection. Non OS
> > statistics
> > > will still be recorded
> > >* in memory and can be viewed by administration tools. However,
> charts
> > > will show no activity and
> > >* no statistics will be archived while sampling is disabled.
> Starting
> > in
> > > 7.0 the default value
> > >* has been changed to true. If statistic sampling is disabled it
> will
> > > also cause various metrics
> > >* seen in gfsh and pulse to always be zero.
> > >* 
> > >* Default: "true"
> > >* 
> > >* Allowed values: true|false
> > >*/
> > >   String STATISTIC_SAMPLING_ENABLED = "statistic-sampling-enabled";
> > >
> > > On Tue, Jan 21, 2020 at 1:06 AM Mario Kevo 
> wrote:
> > >
> > > > Hi,
> > > >
> > > > We are trying to disable archiving statistic in the file by providing
> > > > empty string to --statistic-archive-file. This option doesn't work.
> > > > From the documentation it should work:
> > > > The file to which the running system member writes statistic samples.
> > For
> > > > example: “StatisticsArchiveFile.gfs”. An empty string disables
> > archiving.
> > > > I opened ticket(GEODE-7714<
> > > > https://issues.apache.org/jira/browse/GEODE-7714>) and try to fix
> it,
> > > but
> > > > without success.
> > > >
> > > > As alter runtime command update properties and cache, it checks if
> any
> > of
> > > > these parameters change, but if we set this property to an empty
> string
> > > it
> > > > failed with message
> > > > Please provide a relevant parameter(s).
> > > > We can change for this parameter that it can be an empty string but
> how
> > > > this command works, it goes over all parameters and checks if it is
> > > > changed. In that case if we provide something like
> > > > alter runtime --member=server it will be successiful but shouldn't as
> > we
> > > > didn't provide any parameter.
> > > >
> > > > So the proposal is that we need to add a new parameter called
> > > > --statistic-archiving-enabled  which can be true or false. In case it
> > is
> > > > true we need to provide also --statistic-archive-file.
> > > >
> > > > Any thougths?
> > > >
> > > > BR,
> > > > Mario
> > > >
> > > >
> > >
> >
>