Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: 1. Open Software updates 2. Expand any of the nodes 3. Wait around... More information: Eclipse will take minutes to expand the node to show the subitems downloaded from the update site. It will finally show them. This is on any of the three separate networks (all > 1 Mbs) where I've tried this.
Are you connecting to the Internet through a proxy?
Yes and no. I've tried Software updates both behind a proxy at work and without a proxy at home and some other networks. Same result in all locations. When sitting behind the proxy I used the network settings in Eclipse to configure the proxy settings. Otherwise I'm running with a direct connection setting.
And you're specifically referring to the "Eclipse Project Update Site" and "Ganymede" update site that appear by default in the platform? If it is the Ganymede repository, can you try downloading the file at this link in a web browser to see how long it takes? http://download.eclipse.org/releases/ganymede/content.jar Just trying to understand what might be different for you, since it is fast for many others.
The behavior is the same for all update sites, default Eclipse or those I've added (Checkstyle, m2eclipse, jdepend and some more). Downloading the link is subsecond in a browser. I'm on a 24 Mb fiber connection. Could it be some configuration that is screwed up? I've previously tried to reinstall Eclipse to resolve the problem but to no avail. How would I clean out all configuration that Software update uses? Thanks for helping out!
I did some more digging on this problem. Using Wireshark I was able to prove that Software update tries to connect using a proxy that I've previously used but which is now disabled in the Eclipse configuration (instead "Direct connection to the Internet" is enabled). However, to make things even more intricate, if I try to completely remove the old proxy settings (not just disable them) and save and restart Eclipse, the settings are back. Where do Eclipse save these and why do Software update use them although they are disabled?
With some further fiddling around I was able to get rid of the old proxy settings and now Software update works as expected. It required enabling the use of the proxy, emptying out all values and saving. On restart of Eclipse, the options was now empty and I choose Direct connection again and everything worked fine. Still, Software update seems to be using proxy settings, even if disabled.
I confirm the observation that the "Direct connection to the Internet" setting is ignored if there is a disabled proxy set. This has been annoying me for years and still is, I'd love this to be fixed. My "solution" sometimes is to do a little iptables-DNATting redirecting connections to the disabled proxy (in an unreachable LAN) to the proxy in the current LAN. This way I could even revive "almost dead" eclipses. Is there a way to change the Issue's summery? To say "[Net] Eclipse uses disabled proxy over direct connection"
Niklas could you please give a try at this with 3.5 (http://download.eclipse.org/eclipse/) as many things got fixed in this area. Henrik could you please follow up on that with Niklas
This seems be related to bug 257503 which has been fixed. Moreover the proxy support went through a serious redesign in 3.5 so please check if the problem appears in one of the recent builds.
(In reply to comment #8) > Niklas could you please give a try at this with 3.5 > (http://download.eclipse.org/eclipse/) as many things got fixed in this area. > Henrik could you please follow up on that with Niklas > Sure. Niklas, can you try a recent 3.5 and confirm if it works or not? If it still doesn't we have some more detective work to do :)
This seems to be fixed in 3.5 M7, at least it works for me. I did still get some activity on the proxy address, but the download of the update site still worked so I assume it got through somehow (this was with using "Direct" but having a "Manual" proxy configured). So, for my part, this issue can be closed.
(In reply to comment #11) > So, for my part, this issue can be closed. > sweet! Thanks for testing. Marking this as fixed.
