Re: Balancer persist and inherit stuff in trunk
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 j...@jagunet.com 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 j...@jagunet.com 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 j...@jagunet.com wrote: +1 for both being reset... On Jan 7, 2013, at 4:40 AM, Rainer Jung rainer.j...@kippdata.de 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 rainer.j...@kippdata.de 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
Re: Balancer persist and inherit stuff in trunk
That seems to be an issue w/ slotmem... looking into it. On Jan 9, 2013, at 7:26 AM, Rainer Jung rainer.j...@kippdata.de 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 j...@jagunet.com 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 j...@jagunet.com 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 j...@jagunet.com wrote: +1 for both being reset... On Jan 7, 2013, at 4:40 AM, Rainer Jung rainer.j...@kippdata.de 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 rainer.j...@kippdata.de 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
Re: Balancer persist and inherit stuff in trunk
Fixed in r1430821 On Jan 9, 2013, at 8:45 AM, Jim Jagielski j...@jagunet.com wrote: That seems to be an issue w/ slotmem... looking into it. On Jan 9, 2013, at 7:26 AM, Rainer Jung rainer.j...@kippdata.de 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 j...@jagunet.com 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 j...@jagunet.com 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 j...@jagunet.com wrote: +1 for both being reset... On Jan 7, 2013, at 4:40 AM, Rainer Jung rainer.j...@kippdata.de 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 rainer.j...@kippdata.de 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
Re: Balancer persist and inherit stuff in trunk
Ooops 1430869 On Jan 9, 2013, at 9:15 AM, Jim Jagielski j...@jagunet.com wrote: Fixed in r1430821 On Jan 9, 2013, at 8:45 AM, Jim Jagielski j...@jagunet.com wrote: That seems to be an issue w/ slotmem... looking into it. On Jan 9, 2013, at 7:26 AM, Rainer Jung rainer.j...@kippdata.de 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 j...@jagunet.com 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 j...@jagunet.com 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 j...@jagunet.com wrote: +1 for both being reset... On Jan 7, 2013, at 4:40 AM, Rainer Jung rainer.j...@kippdata.de 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 rainer.j...@kippdata.de 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
Re: Balancer persist and inherit stuff in trunk
re: increased performance. True enough, but we should also be aware that the vast majority of people are still running 2.2.x and that httpd is still seen as a slow, bloated monster compared to nginx, which is gradually being seen as the web-server for the web. On Jan 7, 2013, at 5:36 PM, Stefan Fritsch s...@sfritsch.de wrote: On Sunday 06 January 2013, Jim Jagielski wrote: We could, but it's not my personal pref as RM... After all, ApacheCon will be here before we know it :/ That's probably true ;) FWIW, I see the this dynamic nature of 2.4 as much as a killer feature as the increased performance as related to comparisons between httpd and other web-servers out there, including the fanboys latest flavor. Hence my desire to try to have this in asap, so I can re-dive into the optimized event/simple- MPM hybrid I was working on, which itself I hope to have done by ACNA2013. BTW, I don't believe the increased performance in 2.4 should be overrated. It gives some nice improvements with some workloads, but there are still plenty of cases where scalability remains bad (e.g. ssl or long-lasting proxy-requests).
Re: Balancer persist and inherit stuff in trunk
+1 for both being reset... On Jan 7, 2013, at 4:40 AM, Rainer Jung rainer.j...@kippdata.de 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 rainer.j...@kippdata.de 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
Re: Balancer persist and inherit stuff in trunk
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 j...@jagunet.com wrote: +1 for both being reset... On Jan 7, 2013, at 4:40 AM, Rainer Jung rainer.j...@kippdata.de 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 rainer.j...@kippdata.de 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
Re: Balancer persist and inherit stuff in trunk
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 j...@jagunet.com 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 j...@jagunet.com wrote: +1 for both being reset... On Jan 7, 2013, at 4:40 AM, Rainer Jung rainer.j...@kippdata.de 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 rainer.j...@kippdata.de 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
Re: Balancer persist and inherit stuff in trunk
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. On Jan 8, 2013, at 10:25 AM, Jim Jagielski j...@jagunet.com 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 j...@jagunet.com 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 j...@jagunet.com wrote: +1 for both being reset... On Jan 7, 2013, at 4:40 AM, Rainer Jung rainer.j...@kippdata.de 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 rainer.j...@kippdata.de 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
Re: Balancer persist and inherit stuff in trunk
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 rainer.j...@kippdata.de 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
Re: Balancer persist and inherit stuff in trunk
On Sunday 06 January 2013, Jim Jagielski wrote: We could, but it's not my personal pref as RM... After all, ApacheCon will be here before we know it :/ That's probably true ;) FWIW, I see the this dynamic nature of 2.4 as much as a killer feature as the increased performance as related to comparisons between httpd and other web-servers out there, including the fanboys latest flavor. Hence my desire to try to have this in asap, so I can re-dive into the optimized event/simple- MPM hybrid I was working on, which itself I hope to have done by ACNA2013. BTW, I don't believe the increased performance in 2.4 should be overrated. It gives some nice improvements with some workloads, but there are still plenty of cases where scalability remains bad (e.g. ssl or long-lasting proxy-requests).
Re: Balancer persist and inherit stuff in trunk
On Sat, 5 Jan 2013, Jim Jagielski wrote: I haven't created the patch yet... it seems backwards to generate a backport patchset unless what is currently in trunk is OK. There were some suggestions for improvement made regarding the 2.4 backport that ideally would have been noted and addressed in trunk first. I just want to avoid another go-around ;) Would it be an option to let the changes sit in trunk for a while longer and not include them in 2.4.4? We could still aim for a 2.4.5 not too long after, e.g. before ApacheCon.
Re: Balancer persist and inherit stuff in trunk
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. On Jan 5, 2013, at 1:41 PM, Rainer Jung rainer.j...@kippdata.de 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
Re: Balancer persist and inherit stuff in trunk
We could, but it's not my personal pref as RM... After all, ApacheCon will be here before we know it :/ FWIW, I see the this dynamic nature of 2.4 as much as a killer feature as the increased performance as related to comparisons between httpd and other web-servers out there, including the fanboys latest flavor. Hence my desire to try to have this in asap, so I can re-dive into the optimized event/simple- MPM hybrid I was working on, which itself I hope to have done by ACNA2013. On Jan 6, 2013, at 10:26 AM, Stefan Fritsch s...@sfritsch.de wrote: On Sat, 5 Jan 2013, Jim Jagielski wrote: I haven't created the patch yet... it seems backwards to generate a backport patchset unless what is currently in trunk is OK. There were some suggestions for improvement made regarding the 2.4 backport that ideally would have been noted and addressed in trunk first. I just want to avoid another go-around ;) Would it be an option to let the changes sit in trunk for a while longer and not include them in 2.4.4? We could still aim for a 2.4.5 not too long after, e.g. before ApacheCon.
Re: Balancer persist and inherit stuff in trunk
I haven't created the patch yet... it seems backwards to generate a backport patchset unless what is currently in trunk is OK. There were some suggestions for improvement made regarding the 2.4 backport that ideally would have been noted and addressed in trunk first. I just want to avoid another go-around ;) On Jan 4, 2013, at 2:08 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: Sorry -- I meant to send the below just to Jim, but messed-up the headers in Thunderbird -- and it ended up looking, as if Jim wrote it :( On 04.01.2013 14:06, j...@jagunet.com wrote: On 04.01.2013 13: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 ;) Could you give the link to the patch/issue? I'd be happy to test it with a custom-built 2.4.3 here. Thanks! -mi
Re: Balancer persist and inherit stuff in trunk
On 05.01.2013 10:30, Jim Jagielski wrote: I haven't created the patch yet... it seems backwards to generate a backport patchset unless what is currently in trunk is OK. I can drop in a patch into our 2.4.3 build relatively easily. Building (and testing) from trunk is a more serious undertaking. Yours, -mi
Re: Balancer persist and inherit stuff in trunk
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
Balancer persist and inherit stuff in trunk
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 ;)
Re: Balancer persist and inherit stuff in trunk
On 04.01.2013 13: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;) Could you give the link to the patch/issue? I'd be happy to test it with a custom-built 2.4.3 here. Thanks! -mi
Re: Balancer persist and inherit stuff in trunk
Sorry -- I meant to send the below just to Jim, but messed-up the headers in Thunderbird -- and it ended up looking, as if Jim wrote it :( On 04.01.2013 14:06, j...@jagunet.com wrote: On 04.01.2013 13: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;) Could you give the link to the patch/issue? I'd be happy to test it with a custom-built 2.4.3 here. Thanks! -mi
