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
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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.
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
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 ;)
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
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
20 matches
Mail list logo
