On 5/5/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
On 05.05.2007 04:25, Brian Hayward wrote:
BTW, I did test my patch when 1 host was down in a balancer
configuration. It still seemed to work well.
I would think so. My point was more about that with this setting the
response times of your
On 05.05.2007 04:25, Brian Hayward wrote:
BTW, I did test my patch when 1 host was down in a balancer
configuration. It still seemed to work well.
I would think so. My point was more about that with this setting the
response times of your reverse proxy will increase as it may try all failed
We are experiencing intermittent connect timeout errors. The remote
service is really ok, but it still results in the worker being
disabled.
Setting the proxypass disable period using retry=1 is not good
enough for the application I'm working with (given the number of
requests we do per
On May 4, 2007, at 11:37 AM, Brian Hayward wrote:
I have 2 questions:
1) What are the negative implications of disabling this?
2) Is there a cleaner way to accomplish this?
So you just want to setup Apache so that even if it
thinks there's an error, to just ignore it?
Yea, as it currently stands, one timeout is causing us to lose up to
10 more transactions during the next second (with retry=1)
Thanks,
Brian Hayward
On 5/4/07, Jim Jagielski [EMAIL PROTECTED] wrote:
On May 4, 2007, at 11:37 AM, Brian Hayward wrote:
I have 2 questions:
1) What are the
Well, I doubt completely bypassing setting works to
being in the error state is something you want to do
lightly. :)
PROXY_WORKER_IGNORE_ERRORS is used when setting up
the generic forward and reverse workers, since they
are shared for all requests and not specific
to a balancer/url. I guess
On 04.05.2007 20:16, Brian Hayward wrote:
Yea, as it currently stands, one timeout is causing us to lose up to
10 more transactions during the next second (with retry=1)
With the following patch from trunk you are able to set retry to 0, which
should fix your actual problem:
With the following patch from trunk you are able to set retry to 0, which
should fix your actual problem:
Thanks!
But I think in general it is not advisable to do this at least if you are
load balancing your backend / having a failover configuration. And even if
you do not have such a