A counter has a stat object, then methods are intercepted and duration is added to the stat object (1 by method). Value is copied each 4s. Le 4 nov. 2013 23:23, "Ted Dunning" <ted.dunn...@gmail.com> a écrit :
> I still think that what you need is a thread-safe copy rather than a > thread-safe mutate. Even if you force every thread to do the copy, the > aggregation still still wins on complexity/correctness/performance ideas. > > > On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau > <rmannibu...@gmail.com>wrote: > > > In sirona we collect (aggregate) data each N ms and we can still use > stats > > during aggregation (worse case surely) > > Le 4 nov. 2013 21:48, "Phil Steitz" <phil.ste...@gmail.com> a écrit : > > > > > On 11/4/13 12:12 PM, Romain Manni-Bucau wrote: > > > > But aggregation needs to lock so not a real solution. Lock is fine on > > > real > > > > cases but not in simple/light ones. ThreadLocal leaks...so a trade > off > > > > should be found > > > > > > Depends on the use case. If the use case is > > > > > > 0) launch a bunch of threads and let them gather stats individually > > > 1) aggregate results > > > > > > Then the static aggregate method in AggregateSummaryStatistics that > > > takes a collection as input will work with no locking required. > > > > > > Phil > > > > Le 4 nov. 2013 18:42, "Phil Steitz" <phil.ste...@gmail.com> a écrit > : > > > > > > > >> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote: > > > >>> Hi, > > > >>> > > > >>> ATM sirona (a java monitoring library in incubator) relies a lot on > > > >>> Summary stats object from [math3] but it needed a lock to ensure > > > >>> consistency. I know there is a synchronized version but this one > > > >>> scales less then the locked one. > > > >>> > > > >>> My question is quite simple then: will [math] add an implementation > > > >>> with thread safety guarantee and good performances? I think for > > > >>> instance to the LongAdder of Doug Lea which could be used as a good > > > >>> base. > > > >> The short answer is yes, patches welcome. > > > >> > > > >> Ted makes a good point, though; and there is already some support > > > >> for aggregation in the stats classes in [math] (i.e., you can > > > >> aggregate the results of per-thread stats by using, e.g. > > > >> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending > > > >> this to more stats. > > > >> > > > >> Phil > > > >> > > > >>> Romain Manni-Bucau > > > >>> Twitter: @rmannibucau > > > >>> Blog: http://rmannibucau.wordpress.com/ > > > >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau > > > >>> Github: https://github.com/rmannibucau > > > >>> > > > >>> > --------------------------------------------------------------------- > > > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > >>> For additional commands, e-mail: dev-h...@commons.apache.org > > > >>> > > > >>> > > > >> > > > >> > --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > > >> > > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
