On 11/4/13 9:59 PM, Ted Dunning wrote: > That isn't what I meant. > > Do you really think that more than one metric has to update (increment, > say) at precisely the same time?
Yes, that is the problem. For consistency, you need multiple quantities atomically updated for any of the moment-based stats. The sum or count requires just one; but in general you need more than one. Also, obviously if what you are interested is a consistent statistical summary (like one of the aggregates provides), you need to update all the different stats atomically. I like the LongAddr idea; but to generalize it you basically end up creating a mini M/R framework inside one of the statistical aggregates. Could be done, I guess, but I wonder if what is being built in this case is a more general execution framework for concurrent update of aggregation-friendly objects. Phil > > > On Mon, Nov 4, 2013 at 9:49 PM, Romain Manni-Bucau > <[email protected]>wrote: > >> You cant stop the app cause you take a snapshot of the monitoring metrics >> so yes >> Le 5 nov. 2013 06:46, "Ted Dunning" <[email protected]> a écrit : >> >>> On Mon, Nov 4, 2013 at 8:23 PM, Phil Steitz <[email protected]> >> wrote: >>>> On 11/4/13 3:44 PM, Ted Dunning wrote: >>>>> The copy doesn't have to lock if you build the right data structure. >>>> The individual stats objects need to update multiple quantities >>>> atomically when new values come in. Consistency in the copy >>>> requires that you suppress updates while the copy is in progress >>>> unless you implement some kind of update queue internally. What >>>> exactly do you mean by "the right data structure?" >>>> >>> I was talking about lockless data structures in general. >>> >>> Are you sure that real transactions are a requirement here? >>> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
