Re: [Bug-wget] Timeout switch not working

[Ian Bradshaw]

Hi,

Thank you for the reply. The version is 1.11.4 according to the log (see 
attached - includes debug output). However, it seems like this is the 
latest Windows version according to the SourceForge site, unless I'm 
missing something. I also attach a copy of the wgetrc file, which hasn't 
been edited (to my knowledge) since original installation.

This particular log file is associated with a run that occurred a few 
nights ago. It continued a previous wget download attempt, starting at 
02:30. The last modified date of the log file is 02:31, indicating that 
it only progressed for about 1 minute before stalling. The download in 
question did eventually complete successfully (without human 
intervention) but to trigger another attempt, it had to wait until the 
90 minute timeout for the SSIS Execute Process kicked in.

The issue of a download stalling is random and impossible to predict, 
except to say that it's become a common occurrence that occurs most 
nights, having previously been a very unusual occurrence.

Ian
On 02/10/2012 20:24, Ángel González wrote:
> 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.

--
*

Ian Bradshaw, Director, Argento IT Services Ltd., Email: 
address@hidden, Phone: 07941 995890

*

log_20120930_023011.txt
Description: Text document

wgetrc
Description: Text document