|
|
|
|
Re: importtargetdefinition timeout problem [message #634868 is a reply to message #634639] |
Sun, 24 October 2010 17:51 |
Henrik Lindberg Messages: 2509 Registered: July 2009 |
Senior Member |
|
|
Still not totally clear on what is performing the download when you see
the failure. But, assuming Buckminster is telling p2 to get it. If that
is the case, the transport layer will not report a download that ends in
a timeout on a read as a successful download.
If the file is being served from a "special server" of some sort, it is
worth investigating what the HTTP headers look like and see if there are
issues with the file size and timestamps reported in the http response
(you can view them with a browser plugin such as firefox).
p2 will compare the size and timestamp of files being downloaded, thus
if you failed at some point and have a zero sized file subsequent
attempts may not recognize that something is wrong if the response
headers are wrong.
If behind a proxy, this is always suspect, but if it "works sometimes",
then I am not so sure - it ususally "always breaks" when there are
issues with a proxy - unless the proxy server is unreliable.
Is there a chance that the thing you want to download is present in more
than one of the repositories the p2 instance knows about? Name/ID clash?
That would explain that it sometimes works (say given a timeout, it may
try some other location than the one you expect).
Regards
- henrik
On 10/22/10 4:20 PM, Fabian Baboschi wrote:
> I was looking at the temp folder (C:\WINDOWS\temp) and I saw that a file
> that looked like being the jar that should have been transferred was
> actually present and having size 0 in that temp folder.
>
> About my environment:
> I have one feature that contains this jar. This was in a feature on an
> update site (let's say that it was either far away or though a proxy - I
> haven't isolated the case completely).
> The strange thing that made me think it's a timeout is that all the
> other bundles are downloaded correctly and completely and this one
> always fails - this is 60 MB and the biggest one that works is 40 MB...
> The strange thing is that it works sometimes.
>
> I made a workaround (which works) in my Hudson build namely created a
> target definition only for the "target platform build" in which the
> repository location is a local folder.
> Before executing the buckminster task I actually download the site on
> the hudson's build workspace with wget.
> However, I cannot use the global target definition that is set up for
> the development team.
>
> Is that more clear?
|
|
|
Powered by
FUDForum. Page generated in 0.04173 seconds