Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #181460 +++ Seen with Eclipse 3.3M6 on Windows XP, Sun 1.4.2_13 JVM. Create a new project on a remote file system through EFS - I've been testing with the Remote System Explorer and an SSH connection, - see http://wiki.eclipse.org/index.php/EFS - but any other EFS provider has just the same problem. Quit Eclipse and restart. During startup, from the ResourcesPlugin.start() method the Workspace is opened, which leads to activating the SaveManager, which tries to read the .project file from the EFS provider. The stack backtrace is as follows: Thread [main] (Suspended (breakpoint at line 180 in RSEFileStore)) RSEFileStore.getImpl() line: 180 RSEFileStore.openInputStream(int, IProgressMonitor) line: 261 FileSystemResourceManager.read(IProject, boolean) line: 651 SaveManager.restoreMetaInfo(Project, IProgressMonitor) line: 779 SaveManager.restoreMetaInfo(MultiStatus, IProgressMonitor) line: 759 SaveManager.restore(IProgressMonitor) line: 650 SaveManager.startup(IProgressMonitor) line: 1313 Workspace.startup(IProgressMonitor) line: 1949 Workspace.open(IProgressMonitor) line: 1713 ResourcesPlugin.start(BundleContext) line: 363 [...] This is a bad violation of the API contract as stated in Plugin#start(BundleContext): " Note 2: This method is intended to perform simple initialization of the plug-in environment. The platform may terminate initializers that do not complete in a timely fashion. " Calling out into remote file system operations provided by EFS surely cannot complete in a timely fashion when the EFS provider needs to connect. In our concrete example, the EFS provider requires a correctly initialized resources plugin, so we get an activation circle. This circle can only be broken by a Hack that returns "non-existing" files while resources are not yet initialized properly. This leads to projects not properly opening on Workbench startup, as documented in bug 181460. This is a major limitation of functionality. Suggested fix is to open the workspace in a deferred job, or at least run the SaveManager in a deferred Job and independent of activation of the ResourcesPlugin.
A couple of attempts have been made in the past to decouple workspace initialization from resources plugin startup. The main problem is that most of the IResource API is not usable until the workspace state has been loaded from disk. If we perform startup in a background job, then any calls to API that require the state to be loaded must block until the job completes (essentially resulting in the same problem occurring). Since EFS is really a layer "below" the resource API, it seems a bit odd for an EFS implementation to be relying on IResource API. I'm not sure if there's much we can do about this.
It's certainly true that the RSE EFS provider should not depend on the resources plugin since it is conceptually one layer below. And we will work on fixing this. But still, I'm concerned that when remote projects are involved (i.e. projects which have their .project file reside on a remote host made available through EFS), opening these projects on startup can take too long. I've seen cases where due to DNS name lookup, contacting a single remote server can take in the range of 20 seconds. Having just 3 such remote projects would block Eclipse startup for one minute! Taking into account that deferring the whole workspace initialization may not be practical, I'm wondering if there are other solutions that could be taken specifically for remote projects where reading the .project file can be slow. Here are a couple of ideas - comments welcome: 1. Creating remote projects could be discouraged altogether (i.e. removed from the new project wizard). Instead, people could be encouraged creating the project local but adding remote resources through linked folders. 2. When trying to get the .project file of a project during workspace open, the resources plugin could do this guarded by a separate thread with a timeout (e.g. 1 second). If the .project file is not available after 1 second, it could remain closed at first, but a deferred job could be started to try opening it again later. 3. Whenever creating a remote project (i.e. a .project file is on a filesystem other than "local", the resources plugin could create a local copy of the .project file, such that it is available during early startup. At startup, for all such "cached" projects, special handling occurs -- e.g. including a timeout like proposed in (2), or opening the cached local copy during workspace startup but automatically replacing it with the actual remote copy in a deferred job (just like a "synchronize" operation on those projects performed automatically after resources plugin is started) The commonality between all these suggestions is, that I think the resources system needs to be more aware (and potentially add special handling) for resources that are remote and may thus be slow, unavailable, or subject to other errors.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
