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.