Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Buckminster » importtargetdefinition timeout problem
importtargetdefinition timeout problem [message #634079] Wed, 20 October 2010 13:30 Go to next message
Fabian Baboschi is currently offline Fabian BaboschiFriend
Messages: 41
Registered: December 2009
Member
Hi,

I have a big plugin (60 MB) and I want to import it through a "slow" connection.
What is the timeout of the resolver and how can I change that value?

Thank you.
Re: importtargetdefinition timeout problem [message #634436 is a reply to message #634079] Thu, 21 October 2010 17:05 Go to previous messageGo to next message
Fabian Baboschi is currently offline Fabian BaboschiFriend
Messages: 41
Registered: December 2009
Member
I'm actually able to attach a log about this issue.
The archived plugin below has 61 megabytes and the transfer speed from the update site to the target platform is around 100k.

importtargetdefinition '-A' 'mytargetdefinition.target'
Doing full workspace refresh
Waiting for jobs to end
Unable to load all units for Software Site container of target mytargetdefinition.target
[0]An error occurred while collecting items to be installed
[0.2]session context was:(profile=TARGET_DEFINITION:local:1287654711644.target, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
[0.2]Error closing the output stream for osgi.bundle,my.really.big.plugin,1.2.0 on repository file:/d:/some/folder/hudson/.hudson/jobs/JobName_targetPlatf orm/workspace/build/workspace/.metadata/.plugins/org.eclipse .pde.core/.bundle_pool.
Caused by: [0.2]java.io.IOException: Error unzipping C:\WINDOWS\TEMP\my.really.big.plugin.jar: Unexpected end of ZLIB input stream

my.really.big.plugin.jar from C:\WINDOWS\Temp actually exists in that path but its size is 0 which makes me believe that there's some kind of timeout when transferring the file.

It's strange because all the small plugins (ganymede target platform and 40 other "home made" plugins) get transferred successfully every time.
Re: importtargetdefinition timeout problem [message #634467 is a reply to message #634436] Thu, 21 October 2010 20:02 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik LindbergFriend
Messages: 2509
Registered: July 2009
Senior Member
I do not quite understand what was used to download the file with 0
size. Can you elaborate?
- henrik

Fabian Baboschi <fbaboschi@axway.com> wrote:
> I'm actually able to attach a log about this issue.
> The archived plugin below has 61 megabytes and the transfer speed from
> the update site to the target platform is around 100k.
> importtargetdefinition '-A' 'mytargetdefinition.target'
> Doing full workspace refresh
> Waiting for jobs to end
> Unable to load all units for Software Site container of target
> mytargetdefinition.target
> [0]An error occurred while collecting items to be installed
> [0.2]session context
> was:(profile=TARGET_DEFINITION:local:1287654711644.target,
> phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=,
> action=).
> [0.2]Error closing the output stream for
> osgi.bundle,my.really.big.plugin,1.2.0 on repository
> file:/d:/some/folder/hudson/.hudson/jobs/JobName_targetPlatf
> orm/workspace/build/workspace/.metadata/.plugins/org.eclipse
> .pde.core/.bundle_pool.
> Caused by: [0.2]java.io.IOException: Error unzipping
> C:\WINDOWS\TEMP\my.really.big.plugin.jar: Unexpected end of ZLIB input
> stream
>
> my.really.big.plugin.jar from C:\WINDOWS\Temp actually exists in that
> path but its size is 0 which makes me believe that there's some kind
> of timeout when transferring the file.
>
> It's strange because all the small plugins (ganymede target platform
> and 40 other "home made" plugins) get transferred successfully every
> time.


--
- henrik
Re: importtargetdefinition timeout problem [message #634639 is a reply to message #634079] Fri, 22 October 2010 14:20 Go to previous messageGo to next message
Fabian Baboschi is currently offline Fabian BaboschiFriend
Messages: 41
Registered: December 2009
Member
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?
Re: importtargetdefinition timeout problem [message #634868 is a reply to message #634639] Sun, 24 October 2010 17:51 Go to previous message
Henrik Lindberg is currently offline Henrik LindbergFriend
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?
Previous Topic:Clear metadata when moving workspace to new location
Next Topic:rmap resolution weirdness
Goto Forum:
  


Current Time: Thu Mar 28 23:12:23 GMT 2024

Powered by FUDForum. Page generated in 0.04173 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top