[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] Connect-timeout

From: Thomas Dickey
Subject: Re: [Lynx-dev] Connect-timeout
Date: Thu, 27 Nov 2008 10:53:37 -0500 (EST)

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

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. "

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]