Community
Participate
Working Groups
When I want to update the Eclipse plugins from the main Eclipse server I can select all plugins (e.g. EMF, VE, etc.). But after starting the download Eclipse hangs after some time and also my whole system hangs (Windows XP SP2). The whole TCP/IP stack hangs. It is the problem described here: http://www.microsoft.com/products/ee/transform.aspx?EvtSrc=Tcpip&EvtCat=None&EvtID=4226&EvtCatID=0&EvtType=Warning&EvtTypeID=2&EvtRptTime=1094593275&EvtTZBias=240&CoName=Microsoft%20Corporation&ProdName=Microsoft%c2%ae%20Windows%c2%ae%20Operating%20System&ProdVer=5.1.2600.2180&FileName=xpsp2res.dll&FileVer=5.1.2600.2180 To download properly the not found URL connections should be closed correct. I found e.g. following code in one of the classes of the plugin org.eclipse.update.core : org.eclipse.update.internal.core.HttpResponse.java: public long getLastModified() { if (lastModified == 0) { if (connection == null) try { connection = url.openConnection(); } catch (IOException e) { } if (connection != null) lastModified = connection.getLastModified(); } return lastModified; } In the catch block the URL connection is not disconnected so this connection is a "incomplete outbound TCP connection" (see on Microsoft page) and blocks the processing of further connections. There are probably many more such "incomplete" connections throughout the Update plugin source code. These should be fixed for working under Windows XP. ("With TCP/IP stack hangs" I mean that I cannot open another connection while Eclipse hangs (tries to connect), i.e. browser, email client, chat are not working anymore. I have to kill the Eclipse process to contiune using the system!)
Udo, thanks for this complete report. I will investigate it as soon as I get back from vacation.
I am still at SP1 level, so I can't properly test this. How do you expect to handle the exception thrown? If there is an exception during url.openConnection(), the connection object is still null, so I can't close it. Do you have any suggestions?
Hi Dorian, the problem is not the case when the url could not be opened. The problem with XP(SP2) are all the open connections. I.e. you should close all used connections. Close an open connection like this: if (this.connection instanceof HttpURLConnection) { ((HttpURLConnection) this.connection).disconnect(); } Do this after you used the connection; same as if you close an inputstream after usage. If you have an error case where the connection is already open then close the connection in any of the catch blocks or finalizers. In the catch block close the connection like this (I check also if the connection is not null): } catch (Exception ex) { if (this.connection != null) { if (this.connection instanceof HttpURLConnection) { ((HttpURLConnection) this.connection).disconnect(); } this.connection = null; } } I saw the HttpURLConnection.disconnect() in your source only when the user cancels the connection. It will never be closed in the "normal" case. E.g. in the class HttpResponse: public InputStream getInputStream(IProgressMonitor monitor) throws IOException, CoreException { ... connection = url.openConnection(); ... this.in = connection.getInputStream(); return in; } The code above opens the connection, gets the inputstream, returns the inputstream, but never closes the connection, or? Also the code i mentioned in the first bug submit should look like this: public long getLastModified() { if (lastModified == 0) { if (connection == null) try { connection = url.openConnection(); } catch (IOException e) { ----> if connection != null -> close it } if (connection != null) lastModified = connection.getLastModified(); ----> close connection } return lastModified; } I hope this makes the solution clearer?
Thanks. I was only pointing out that connection was always null in the catch block, because if the url.openConnection fails, connection is never assigned, and it was null to start with. So the line with ----> below is redundant. public long getLastModified() { if (lastModified == 0) { if (connection == null) try { connection = url.openConnection(); } catch (IOException e) { ----> if connection != null -> close it } I will take a look at the other usages. One potential drawback with closing connections after the use in a method will involve recreating them a couple of times. Having the connection cached in the HttpResponse avoids it. On the other hand, if not closed, it has the potential to create the problems you describe.
Udo, are you still seeing problems with the recent drivers (M5) ?
(In reply to comment #5) > Udo, are you still seeing problems with the recent drivers (M5) ? I just checked with 3.1M6, and the problem still exists. Checking for updates from the eclipse site takes ages, then after a while eclipse displays an error message which I can't read because the whole IDE is frozen. However, this time other applications seemed not to be affected.
Thanks. Did you run the update search in backround ?
(In reply to comment #7) > Thanks. Did you run the update search in backround ? No. When it was apparent the update would take a while I switched to firefox and surfed the web, but I didn't use the "Run in background" dialog button.
Branko, please investigate this problem and report any possible performance side-effects of the aggressive HTTp connection closing.
I could not reproduce the problem on our xp sp2 machine. I tried with current nightly build, m6 and m7. I have also inspected and profiled the code and I could not find where this problem might arise.
Created attachment 21773 [details] org.eclipse.ui.ide.patch.ConfigurationLogUpdateSection change
Comment on attachment 21773 [details] org.eclipse.ui.ide.patch.ConfigurationLogUpdateSection change patch is for different bug
Hi, we still had this bug in E3.1M6. But in E3.1M7 the bug does not exist anymore. Thanks!
FIXED, thanks Udo
I see this (or a similar) bug with Eclipse 3.2 RC5 and RC6 running on WinXP SP2, Sun J2SE Version 1.5.0 (Build 1.5.0_07-b03). Both, Eclipse and the Java VM, are fresh installations. Unlike in the original description, only the TCP/IP stack, not the entire system seems to hang, causing existing connections to time out and preventing new connections from being established. Steps to reproduce the bug: 1. Start Eclipse. 2. Download the Eclipse Modeling Framework from the Callisto discovery site 3. Wait for it to download, then click 'Install' in the Verification dialog ("Warning: You are about to install an unsigned feature.") In the progress dialog, the progress bar goes up to about 20% ("Initializing..." in details) and a few seconds later you notice other connections dropping (e.g. IRC) and new connections cannot be established (IRC reconnection attempts, opening URLs in a webbrowser, etc.) After waiting a bit more, an exception message comes up: An exception occured while downloading feature from "http://download.eclipse.org/callisto/releases/features/org.eclipse.emf_2.2.0_v200605151820.jar" After the exception message popped up, internet connections are possible again.
I can confirm Andreas observation on the recent Eclipse 3.2 release candidates.
Andreas, Can you please check bug 101575 and especially look at the comment 33. Your problem looks a lot like the problem described there
(In reply to comment #17) > Andreas, > Can you please check bug 101575 and especially look at the comment 33. Your > problem looks a lot like the problem described there > Thanks for the hint, that workaround helped.
glad I could help
