httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: prefetch proxy
Date Thu, 03 Nov 2011 12:11:30 GMT
On Thu, Nov 3, 2011 at 7:58 AM, "Plüm, Rüdiger, VF-Group"
<ruediger.pluem@vodafone.com> wrote:
>
>
>> -----Original Message-----
>> From: Jim Jagielski [mailto:jim@jaguNET.com]
>> Sent: Donnerstag, 3. November 2011 12:53
>> To: dev@httpd.apache.org
>> Subject: Re: prefetch proxy
>>
>>
>> On Nov 2, 2011, at 7:40 AM, Plüm, Rüdiger, VF-Group wrote:
>>
>> >
>> > I think a timeout should be handled like it is now as failing on
>> > a slow client is IMHO a desired action by the admin. If he
>> wants to give
>> > the client more time he should configure a higher timeout.
>> > For other errors like 'Resource temporarily unavailable' we
>> should log and possibly
>> > retry. But the question is: Why does this error happen in
>> the first place?
>> > What is the root cause of it and what can be done to remove it?
>> > Is this error something that can just happen and we should
>> gracefully live
>> > with by retrying? And if we are retrying how often do we do
>> this to avoid an endless loop?
>> >
>>
>> I'm fine with with having a set number of retries with EAGAIN and
>> treating a timeout as an error. If we exhaust the retries, we
>> simply break out of the prefetch loop and continue on, and let
>
> Continue without prefetch in the EAGAIN case and hope for better times
> when we need the body really later?
>
>> a continued Resource temporarily unavailable be handled as it
>> normally would.
>
> So as an error?
>
>>
>> Sound OK?
>>
>
> In general yes. See the questions for details above :-)
>

Maybe I misunderstood, but I thought Rüdiger's original point was on
track: EAGAIN here is a bug to fix somewhere since EAGAIN from
blocking read is should-not-occur, and this code doesn't need to grow
another error path.

Mime
View raw message