Statistics are supposed to work even if you don't have sampling enabled. For example you could turn off sampling and not have a statistic archive but could still run a gfsh command that fetches a bunch of stats from the running system or use the pulse tool.
However you can leave sampling turned on even if you do not have a statistic archive and it is true that our current OSStats (linux, windows, solaris) and VMStats are only updated when sampling is enabled. If you go with that then you just need to make clear that your sampler will only be called if the config property "statistic-sampling-enabled" is true and the frequency of calls will be determined by the config property "statistic-sample-rate". On Thu, Jun 2, 2016 at 11:23 AM, Jens Deppe <[email protected]> wrote: > If the methods are providing a Supplier (to the Statistic) shouldn't they > be called 'set{Int,Long,Double}Supplier'? > > On Thu, Jun 2, 2016 at 11:04 AM, Dan Smith <[email protected]> wrote: > > > Replies inline. > > > > On Thu, Jun 2, 2016 at 10:04 AM, Darrel Schneider <[email protected] > > > > wrote: > > > > > It is not clear to me how the new apis behave. > > > Is the supplier for a particular id/name/descriptor remembered by the > > > Statistics instance? So if you wanted to add an intSupplier for a int > > > statistic you would do it once by calling sampleInt? > > > > > > > Yeah, that's what I was going for. You install the supplier once and then > > it gets called every sample. > > > > > > > > > The name of these methods give the impression that calling it will > take a > > > sample. Perhaps it should be setSampler? Do you need the type (int, > long, > > > etc) in the name or is overloading ok? > > > > > > > I'll rename it to setSampler, that seems clearer. Name overloading should > > work, but I was trying to be consistent with the existing methods. We > have > > incInt, intLong, incDouble. Should I follow a different pattern for these > > setSampler methods? > > > > > > > Does the supplier need to match the type of the stat otherwise you get > > > IllegalArgumentException? > > > > > > > That seems like a good idea, I'll clarify that in the javadocs. > > > > > > > Can you only have one sampler registered for a particular stat? If so > > > should these methods return the old one? > > > > > > > Seems like a good idea. I was also thinking maybe for completeness if you > > set the sampler to null it will remove it. I'll clarify the javadocs. > > > > > > > How does a sampler interact with the existing methods on the same stat? > > Do > > > the "get" methods implicitly call the sampler to compute the result > they > > > return? If so then the "set" and "inc" methods become noops. > > > > > > I was thinking get would just return the last sampled value - it would > > not > > trigger an immediate recomputation. But it's true that set and inc are > > basically useless if you have a supplier set. > > > > -Dan > > >
