Re: [Bug-wget] Timeout switch not working

[Ángel González]

On 30/09/12 19:44, Ian Bradshaw wrote:
> Hi,
>
> I am having some trouble with a wget task that is performing an HTTPS
> download of a large file (a 2.9GB 7Zip archive) every night. It is
> scheduled to run as part of an SSIS package, using the SSIS Execute
> Process task. The wget arguments passed are as follows (I've replaced
> sensitive information with the "x" character):
>
> --http-user=SMP\xxxxxxxx --http-passwd=xxxxxxxx
> --output-document=C:\DB_Downloads\xxxxxxxx.7z
> --output-file=C:\DB_Downloads\log.txt --continue --timeout=300
> --tries=20 --no-check-certificate
> https://download.xxxxxxxx.net/xxxxxxxx/xxxxxxxx.7z

> I am able to achieve a successful download of the file if I configure
> enough SQl Server Agent job steps to kill wget and launch another
> instance of the SSIS package. Sometimes the file will download
> successfully with one or two runs of the SSIS package, sometimes it
> needs up to five attempts. SSIS is currently configured to allow 90
> minutes for the download and the client site has a 10Mbps leased line
> to the Internet. There's no way to predict how much of the 90 minutes
> will be spent actively progressing the download and how many will be
> spent idle. For example, download attempt 1 may last for 30 minutes
> then become idle, download attempt 2 may last for the full 90 minutes,
> download attempt 3 may last for just 1 minute, then download attempt 4
> may successfully complete the download with further 20 minutes.
>
My first guess would be to try running it without SSIS, directly on the
console, and seeing if there's some difference (it's unlikely, though).


> I am using the Win32 wget.exe from SourceForge and it's been working
> fine for the best part of two years.
Which url/version? It is probably an old wget version.


> I think something has changed on the side of the download server but
> this is the domain of a third party. I've wondered if they have
> recently put in some kind of IPS that is randomly blocking the data
> packets but this is just speculation and the third party involved
> claim nothing has changed on their side. My question is: why does the
> timeout switch not help in this scenario and is this therefore a bug?
The timeout should be triggering in your scenario, so yes, it'd be a
bug. Although it may be fixed in a newer version.