Community
Participate
Working Groups
I have created an update site with one feature that contains two plugins, where one plugin depends on the other. These plugins are wrappers for some open source JARs. When using Eclipse's Update Manager to update from a local file:c:/testsite2 there is no problem, no slowdown. However, when installing over http, as in http://mymachine/testsite2 it takes upwards of 5 minutes or more for the install to succeed. I have a ZIP file with the update site that I would like to provide to the Eclipse Update developers to use for tracking down this issue.
Unzip the Zip file onto a machine running a web server, such as apache and attempt to install into Eclipse using the update manager over HTTP. Since the zip file is 2262 KB in size, it is too large to attach... I have provided a link, below... http://www.magma.ca/~drifting/eclipse/testsite.zip
John, There is number of similar, unreproducible by update developers bugs. Please answer the following: OS, service pack level, NIC model, JRE, connection speed, server software. Thanks.
Tested installing from a server at work to a machine at home. The problem is not releated to the content of the site. Works like a charm (took about 6s to download).
OS : Microsoft Windows XP Professional Version 2002 Service Pack 2 JRE : Sun Java 2 JDK 1.4.2_07 Connection Speed... I'm going between two machines at work over a local area network... It is fast. Server is running Windows XP Prof Version 2002 Service Pack 2 App server is Apache HTTP Server 2.0.54 I am using Eclipse 3.1 Release version, no patches or updates. This is consistently reproduceable here on every machine I have tried. Note: if I attempt to use IIS on my own machine, not only does eclipse block, but so does the task bar in Win XP on my machine.
Konrad, I unpacked the zip file directly into http://www.magma.ca/~drifting/eclipse/testsite and am able to install from there with no delays.... hmmmm... maybe something to do with the way apache is configured on my other server???
(In reply to comment #3) > Tested installing from a server at work to a machine at home. The problem is > not releated to the content of the site. Works like a charm (took about 6s to > download). Konrad, I know there is a contingency of Eclipse developers/contributors in Ottawa, Ont. Canada... Given this is reproducible in our environment, would someone be willing to come check it out? FYI... some more information. I originally encountered this problem while using the Stand Alone update classes (i.e. InstallCommand, DisableCommand, UninstallCommand)... Here is the interesting behaviour with those... If you start up Eclipse and install the example using InstallCommand, there is no delay. What is noticed is that all the jars are cached in the temp directory, however (and retained until Eclipse is shut down). If you then Disable and Uninstall the feature and then attempt to Install again, the cached jars are used instead... however, calls are made to download the jars again (using "GET") for the purpose of extracting the Message Header field "lastModified", to determine if the jars had been updated since last cached. It is during this phase that the delay occurs... i.e. blocked on a socket read while doing this check... Cheers, John.
OK... we have figured out the problem... My test "server" is actually Windows XP Professional 2002... Windows XP has a limit of 10 incoming concurrent connections... taking into account that some of the connections are used for other reasons, we only have 5 available... Placing tcpmon between my notebook and my server demonstrates 7 active concurrent connections between eclipse and the "server"... We block for 5 minutes waiting for two of the connections to time out before the install resumes... In fact, if you attempt to use the browser to the same machine, it, too, will hang until there is an available connection. This is why we (and you) are unable to reproduce this problem when placing the update site on a true "server" that doesn't have Win XP's built in limitation on the number of concurrent connections. Now, the question is, why are so many connections required/necessary during the install? Are there connections that are being left open that could have/should have, been closed? Could this overhead be reduced? Cheers, John
Thank you John. This is very important information. We are aware of some extra connections, and inability of efficient closure of unsed ones. You were able to confirm, that with certain server, it results in nonresponsive clients. We will continue working on improving networking part of Install/Update, and now have a good clue where to install a server to have a chance to reproduce.
*** This bug has been marked as a duplicate of 101575 ***
