Re: [Lynx-dev] Connect-timeout

[Thomas Dickey]

On Wed, 26 Nov 2008, address@hidden wrote:

> We're using lynx in a job that's scheduled every night. In the job lynx 
> makes a call to a certain web-url.
>
> The problem we have is that linx give the following message:
>
> HTTP request sent; waiting for response.
>
> Alert!: Socket read failed for 180,000 tries.
>
> Connection interrupted.

This is a different timeout than "connect_timeout".

connect_timeout is used in HTDoConnect().

The read-failed message comes from HTDoRead().

They're similar loops, but in different places.  We could make the reads 
timeout in the same way, but haven't (no particular attention was given to 
this, though now that it's pointed out, someone did report a problem with 
it a few years ago).

For reference, see the search results for "connect_timeout" and "180,000"
on the mailing list http://lists.gnu.org/archive/html/lynx-dev/

> The call to the url starts some processing which takes more than 5 
> hours.
>
> In the config file I saw a property connect_timeout=18000.
>
> When I understand well, when 18000 seconds pass without linx receiving 
> any response form the request it lanched it will generate the above 
> error.
>
> So what we did is double the connect_timeout to 36000 seconds. But this 
> doesn't work.
>
>
>
> Are my assumptions concering the connect_timeout property wrong ?
>
> Is there a way to change this behavior ?
>
>
>
> Kind regards,
>
>
>
> Dries De Moor
>
>
>
>
>
>
>
> ELECTRABEL NV/SA, 8 Regentlaan - Boulevard du R?gent
> 1000 Brussel - Bruxelles, 0403170701, RPR/RPM Brussel/Bruxelles
> =======================================================
> "This message is confidential. It may also be privileged or otherwise protected by 
> work product immunity or other legal rules. If you have received it by mistake please let 
> us know by reply and then delete it from your system; you should not copy it or disclose 
> its contents to anyone. All messages sent to and from Electrabel will be monitored to 
> ensure compliance with internal policies, to protect our interests and to eliminate 
> potential malware. Emails are not secure and cannot be guaranteed to be error free as 
> they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who 
> communicates with us by email is taken to accept these risks. "
>
> http://www.electrabel.be/homepage/general/disclaimer_EN.asp
> =======================================================

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net