Ooops 1430869 On Jan 9, 2013, at 9:15 AM, Jim Jagielski <[email protected]> wrote:
> Fixed in r1430821 > On Jan 9, 2013, at 8:45 AM, Jim Jagielski <[email protected]> wrote: > >> That seems to be an issue w/ slotmem... looking into >> it. >> >> >> On Jan 9, 2013, at 7:26 AM, Rainer Jung <[email protected]> wrote: >> >>> On 08.01.2013 17:09, Jim Jagielski wrote: >>>> Rainer, does the below address your concern and make >>>> it OK that the current behavior acts the way it does >>>> and we're OK to keep it that way. >>> >>> Yes sort of. We now know/remember why there are subtleties and since >>> some statistical counters are dual purpose - statistics/monitoring and >>> LB decision data it seems we need to give up a 100% consistency goal. >>> I'm OK with that as it is now. >>> >>> Did you have a look at the other topic about the "Used" shm slot counter? >>> >>> Regards, >>> >>> Rainer >>> >>>> On Jan 8, 2013, at 10:25 AM, Jim Jagielski <[email protected]> wrote: >>>> >>>>> Yeppers... >>>>> >>>>> actually, transferred and read *are* persisted, it's just >>>>> that the bytraffic lbmethod is smart enough to know that >>>>> when the config is changed, those counters need to >>>>> be reset and, by default, a restart is a "change". >>>>> Since elected is never used for any sort of lbmethod, >>>>> it never is reset and so the persist "holds". >>>>> >>>>> So the idea is that lbmethods should reset any potential >>>>> persisted values iff it makes sense for that lbmethod. >>>>> bytraffic resets transferred/read but byrequests doesn't, >>>>> for example. >>>>> >>>>> On Jan 8, 2013, at 9:49 AM, Jim Jagielski <[email protected]> wrote: >>>>> >>>>>> Hold on a tic... let me go thru my notes. I seem to recall >>>>>> an issue I hit. >>>>>> >>>>>> On Jan 8, 2013, at 9:28 AM, Jim Jagielski <[email protected]> wrote: >>>>>> >>>>>>> +1 for both being reset... >>>>>>> >>>>>>> On Jan 7, 2013, at 4:40 AM, Rainer Jung <[email protected]> wrote: >>>>>>> >>>>>>>> On 06.01.2013 17:48, Jim Jagielski wrote: >>>>>>>>> I had thought that I has responded to that orig >>>>>>>>> email that both below issues where "by design" >>>>>>>>> but could be adjusted if need be or desired. >>>>>>>>> >>>>>>>>> I have no opinions either way, but to be Used seems >>>>>>>>> more session based and Elected is more long-term >>>>>>>>> statistical. >>>>>>>> >>>>>>>> Hmmm, but the "Used" field should give information about shm slots >>>>>>>> occupied by configured balancers. Isn't the info (=0) wrong after a >>>>>>>> restart? >>>>>>>> >>>>>>>> Concerning the long term statistical values I'm undecided like you, but >>>>>>>> I think we should handle them in a consistent way, so "traffic" and >>>>>>>> "elected" should either be both persisted or both reset. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Rainer >>>>>>>> >>>>>>>>> On Jan 5, 2013, at 1:41 PM, Rainer Jung <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On 04.01.2013 19:48, Jim Jagielski wrote: >>>>>>>>>>> Have people had a chance to test, review and try the balancer >>>>>>>>>>> persist and inheritance stuff in trunk? I want to make >>>>>>>>>>> sure that we have some level of verification and agreement >>>>>>>>>>> there before I work on the backports for 2.4 ;) >>>>>>>>>> >>>>>>>>>> I didn't see any changes with respect to two of my original comments: >>>>>>>>>> >>>>>>>>>> The "Used" counters (number of shared mem slots) in balancer manager >>>>>>>>>> drops to "0" after restart/reboot´with persist on. This seems >>>>>>>>>> strange. >>>>>>>>>> Not that "Used" does *not* have anything to do with request counting. >>>>>>>>>> >>>>>>>>>> Second the "Elected" counter is persisted but e.g. the traffic >>>>>>>>>> counter's >>>>>>>>>> not. This seems somewhat inconsistent. I have no strong opinion >>>>>>>>>> whether >>>>>>>>>> to persist statistics or not, but we might want to behave >>>>>>>>>> consistently. >>>>>>>>>> >>>>>>>>>> I did not observe any functional changes after my Mail from Dec. 14, >>>>>>>>>> right? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Rainer >>> >> >
