On 5/7/2013 2:00 PM, Jim Jagielski wrote:
> Agreed... An "all or nothing" setting will likely create more
> trouble than not.
>
> On May 7, 2013, at 8:08 AM, Eric Covener wrote:
>
>> On Tue, May 7, 2013 at 6:24 AM, Thomas Eckert
>> wrote:
>>> Attached patch contains a directive to improve the err
Agreed... An "all or nothing" setting will likely create more
trouble than not.
On May 7, 2013, at 8:08 AM, Eric Covener wrote:
> On Tue, May 7, 2013 at 6:24 AM, Thomas Eckert
> wrote:
>> Attached patch contains a directive to improve the error marking of workers.
>> Basically, some errors will
On 5/7/2013 3:41 AM, Daniel Gruno wrote:
Hi all,
I did some talking with Jim and Rich (or was it Rainer, I forget) during
ApacheCon, in which we agreed that we need to plug our modules directory
some more. I totally forgot all about this, but since it's never too
late to get something like this d
Links don't imply endorsement (although maybe we need to say that explicitly),
so I think that links are a very good thing when they help real people solve
real problems.
So, +1
On May 7, 2013, at 6:41 AM, Daniel Gruno wrote:
> Hi all,
> I did some talking with Jim and Rich (or was it Rainer,
On Tue, May 7, 2013 at 6:24 AM, Thomas Eckert
wrote:
> Attached patch contains a directive to improve the error marking of workers.
> Basically, some errors will cause a worker to be marked as "in error" while
> others don't. I can't see a reason for this so I added a directive to have
> all error
+1.
PS: The ap_proxy_define_balancer() stuff is there for future enhancements
(creating balancers on the fly, instead of just workers).
On May 7, 2013, at 4:07 AM, Thomas Eckert wrote:
> > However, looking at your patch, having to lock the mutex for
> > ap_proxy_get_worker() looks wrong. I
Hi all,
I did some talking with Jim and Rich (or was it Rainer, I forget) during
ApacheCon, in which we agreed that we need to plug our modules directory
some more. I totally forgot all about this, but since it's never too
late to get something like this done, I am now contemplating adding a
link f
Attached patch contains a directive to improve the error marking of
workers. Basically, some errors will cause a worker to be marked as "in
error" while others don't. I can't see a reason for this so I added a
directive to have all errors mark the error correctly - especially useful
for automated s
> However, looking at your patch, having to lock the mutex for
> ap_proxy_get_worker() looks wrong. I think it should be passed r->pool
> instead of conf->pool.
I checked how ap_proxy_get_worker() is used in other places and also what
is done with the pool inside and you are right. It really shoul
