httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: prefetch proxy
Date Fri, 04 Nov 2011 20:14:06 GMT

On Nov 4, 2011, at 4:23 AM, Rüdiger Plüm wrote:

> 
> 
> Am 03.11.2011 20:00, schrieb Jim Jagielski:
>> 
>> On Nov 3, 2011, at 2:37 PM, Jeff Trawick wrote:
>>> 
>>> I'm not disputing that there is some undiagnosed situation where
>>> APR_ETIMEUP is seen.
>>> 
>>> I am looking for confirmation that APR_ETIMEUP is the expected value.
>>> 
>> 
>> It's hard to diagnose what the value should be... all I know
>> is that what is being returned thru APR is EAGAIN, and this
>> causes issues during the prefetch phase.
> 
> But I agree with Jeff that this looks like a bug in APR that should be fixed
> there. We should NOT get an EAGAIN here. Only a timeout or something more
> fatal (like a closed socket).
> 

I agree with that... But again looking at APR as an "external"
dependency, we know that APR does, at times, return a EAGAIN
when it shouldn't, and so httpd should work around that.

It all depends on how tightly we, as the httpd pmc, wish to
be "bound" by the APR pmc, if you get my meaning.


>> 
>> For sure, even if we allow EAGAIN, if the underlying condition
>> still causes a read error, we'll hit it when we really start
>> reading in the body.
>> 
>> I guess the main idea is that if we're going to prefetch, and
>> I'm trying to remember why we do, then we should be more
>> lenient on what we determine as an "unrecoverable" error. If
>> we hit EAGAIN and/or TIMEUP, I'm find with logging it and then
>> breaking out of that loop, even without any retries.
> 
> Fine with me for TIMEUP and as a temporary fix for EAGAIN. But we
> should find the root cause for EAGAIN.
> 

+1... (obviously ;) )


Mime
View raw message