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.
