Community
Participate
Working Groups
In my workspace I have a version of org.eclipse.swt loaded from our local repository. I went to the repository view and added org.eclipse.swt from the stream on dev.eclipse.org. After processing a little under 1/4 the operation stalled at org.eclipse.swt.widgets.Tree.java (34k of 53k). Clicking cancel has no effect. The text in the progress dialog flickers occasionally. It looks like it keeps getting updated with the same old Tree.java progress (or lack thereof).
We had a newsgroup posting from Marcio Marchini that was similar.
On a subsequent retry (I killed Eclipse and restarted) I got the error message "Cannot close connection". I've seen that earlier today when trying to synchronize to the new dev.eclipse.org. In both cases I got it fairly early on, i.e. way before the synchronize was done.
I keep getting the "Error cannot close connection" when I try to synchronize with the entire org.eclipse.swt. When I syncronize with each folder individually or only a few folders at a time it works.
This may be related. I started with a new workspace and had Automatic Build on. I then "Added to Workspace" the org.eclipse.swt project. I got to a point where I was hung. Processing was occurring (100% of the CPU being utilized) but progress was not being made. The "adding XXX bytes of YYY bytes" dialog was updating (I could see it flash), but no progress was being made (i.e., the XXX bytes was not increasing). The first time I got stuck I waited about 20 minutes and then killed Eclipse. The second time, I waited less (about 5 minutes). I was able to load by turning automatic build off.
Uploaded the offending workspace to walleye:/va2000/incoming/forMichaelV/4911.zip This workspace also shows (I think) the "Cannot close connection" error when synchronizing org.eclipse.swt. If not, I can send another workspace where I definitely do see that problem.
*** Bug 4959 has been marked as a duplicate of this bug. ***
I reproduced the stalled "Add to Workspace" at home over VPN. The culprit was the ServerPacket::fill() method. And I think this explains why this is hard to reproduce in the office. It was easy to reproduce, basically happening all the time :) When totalBytesRead was zero (e.g. the entire packet was read during the last fill or the entire buffer was filled) then this works fine because totalBytesRead is always 0. However, when the client read faster than the bytes where read from the line, then totalBytesRead increased and the while loop was being skipped when there are actual bytes still left to be read. This was causing the infinite loop. I have refactored the fill method to always read bytes if they are available. I can now sync and add to workspace SWT, UI plugins. I tried several times and it seems to work now. Why this was not happening before is a mystery and worries me somewhat. I am not 100% confident in this fix without further testing and at least a code review (another pair of eyes) on the Client/ServerPacket classes in the SSH plugin.
*** Bug 5335 has been marked as a duplicate of this bug. ***
Fixed in v207