Bug 219164 - [efs][ssh][performance] Eclipse hangs when importing a project that contains a linked resource for a large, slow, efs-ssh-shared file system
Summary: [efs][ssh][performance] Eclipse hangs when importing a project that contains ...
Status: ASSIGNED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: dsdp.tm.rse-inbox CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: performance
Depends on: 219169
Blocks:
  Show dependency tree
 
Reported: 2008-02-15 15:32 EST by Martin Oberhuber CLA
Modified: 2012-03-08 02:59 EST (History)
1 user (show)

See Also:


Attachments
The project causing the trouble (501 bytes, application/x-zip-compressed)
2008-02-15 15:32 EST, Martin Oberhuber CLA
no flags Details
Full Thread dump while Eclipse hangs (19.94 KB, text/plain)
2008-02-15 15:33 EST, Martin Oberhuber CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2008-02-15 15:32:17 EST
Created attachment 89878 [details]
The project causing the trouble

* Extract attached www-dsdp-remote.zip to somewhere
* In RSE, create an SSH-Only connection to dsdp.eclipse.org and connect it
* File > Import > Existing Project into Workspace,
  point to the extracted file.

The dialog named "Importing" just hangs.

The .project file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
	<name>www-dsdp-remote</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
	</buildSpec>
	<natures>
		<nature>net.sourceforge.phpeclipse.phpnature</nature>
	</natures>
	<linkedResources>
		<link>
			<name>dsdp</name>
			<type>2</type>
			<locationURI>rse://DSDP.ECLIPSE.ORG/var/www/html/dsdp</locationURI>
		</link>
	</linkedResources>
</projectDescription>


-----------Enter bugs above this line-----------
TM 3.0M5
installation : eclipse-SDK-3.4M5 (I20080207-1530), cdt-4.0.0M5, emf-2.4.0M5
     DSF-N20071113, ECF-2.0m4, PHPEclipse-1.2.0-Nightly, Releng.Tools-3.4M5,
     Subversive-0.7.0m4, SWT-MemMonitor, WR-Retriever-3.0.v20070604
RSE install  : RSE-SDK-I20080212-2045, TM-terminal, TM-discovery
java.runtime : Sun 1.6.0_02-b06 -Xmx512m -XX:MaxPermSize=128m
os.name:     : Windows XP 5.1, Service Pack 2
------------------------------------------------
systemtype   : Windows-local, Dstore-win, Dstore-linux
targetos     : Red Hat Enterprise Linux WS release 4 (Nahant Update 3)
targetuname  : Linux parser 2.6.9-34.EL #1 i686 athlon i386 GNU/Linux
targetvm     : Sun Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode)
------------------------------------------------
Comment 1 Martin Oberhuber CLA 2008-02-15 15:33:46 EST
Created attachment 89880 [details]
Full Thread dump while Eclipse hangs

Attached is a full thread dump of the hanging Eclipse application.

It looks like the "Import Project" action starts a ModalContextThread, in which RSE / JSch wants to access the remote file system. But eventually, JSch just keeps reading its PipedInputStream and does not wake up any more.

All of Eclipse is blocked, no chance to save any data etc.
Comment 2 Martin Oberhuber CLA 2008-02-15 15:34:33 EST
Note that in addition to Eclipse-3.4M5 I also have JSch-0.1.37 in my installation, so the hang seems to be caused by JSch-0.1.37.
Comment 3 Martin Oberhuber CLA 2008-02-15 17:21:58 EST
See also bug 218387.

I pruned the remote folder hierarchy down to 851 files in 152 directories, and copied the entire hierarchy to a local server with fast network access. Now the import ran smoothly.

I then tried again on the (pruned) slow remote file system, and it took some time in the range of minutes, but completed eventually.

Before the pruning, the folder hierarchy was really huge, so it might be that this was not really a program hang-up but it just took that long. I will continue monitoring the situation.

The real problem of the issue seems to be bug 219169, that the import wizard is not cancelable and runs in the modal context thread rather than performing at least refresh operations on deeply nested children in background.