Comment 1 Greg Watson 2007-06-28 11:59:49 EDT

Created attachment 72695 [details]
connection profile

Comment 2 Greg Watson 2007-06-28 12:04:38 EDT

Created attachment 72699 [details]
more profiles

Comment 3 Greg Watson 2007-07-20 17:19:27 EDT

This doesn't appear to be a profile corruption problem. I've tried removing all the profiles and recreating new ones and I'm still getting this problem intermittently. It looks like 'anchor' is null in org.eclipse.rse.internal.persistence.PropertyFileProvider.getSaveJob(). Since anchor is only set when getAnchor() is called, I'm wondering if this is because I'm not doing anything with the UI before the profiles are being restored? Maybe this is some kind of UI dependency on core?

In any case, RSE is not useable for providing remote services for PTP with this bug present.

Comment 4 Martin Oberhuber 2007-07-23 12:51:55 EDT

Greg I'd love to help you but it's hard without more information.

Could you try replacing the variable "anchor" in PropertyFileProvider line 151 by a getAnchor() call? This should fix the issue reported by you.

Comment 5 Martin Oberhuber 2007-07-23 12:52:56 EDT

A traceback (log entry) from your NPE might help understanding why getAnchor() has not been called by the persistence framework before.

Comment 6 Greg Watson 2007-07-23 13:21:55 EDT

Here are the tracebacks. I'll try changing to getAnchor() next and see what that does.

Traceback from error 'Error creating default pool':

java.lang.NullPointerException
at org.eclipse.rse.internal.persistence.PropertyFileProvider.getSaveJob(PropertyFileProvider.java:151)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.save(RSEPersistenceManager.java:423)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.commitProfile(RSEPersistenceManager.java:138)
at org.eclipse.rse.internal.core.model.SystemProfile.commit(SystemProfile.java:216)
at org.eclipse.rse.internal.core.filters.SystemFilterPool.commit(SystemFilterPool.java:1246)
at org.eclipse.rse.internal.core.filters.SystemFilterPoolManager.commit(SystemFilterPoolManager.java:1645)
at org.eclipse.rse.internal.core.filters.SystemFilterPoolManager.createSystemFilterPool(SystemFilterPoolManager.java:479)
at org.eclipse.rse.subsystems.files.core.subsystems.RemoteFileSubSystemConfiguration.createDefaultFilterPool(RemoteFileSubSystemConfiguration.java:334)
at org.eclipse.rse.core.subsystems.SubSystemConfiguration.getFilterPoolManager(SubSystemConfiguration.java:1612)
at org.eclipse.rse.core.subsystems.SubSystemConfiguration.getAllSystemFilterPoolManagers(SubSystemConfiguration.java:2601)
at org.eclipse.rse.internal.core.subsystems.SubSystemConfigurationProxy.restore(SubSystemConfigurationProxy.java:268)
at org.eclipse.rse.internal.core.subsystems.SubSystemConfigurationProxy.getSubSystemConfiguration(SubSystemConfigurationProxy.java:248)
at org.eclipse.rse.ui.internal.model.SystemRegistry.getSubSystemConfiguration(SystemRegistry.java:304)
at org.eclipse.rse.internal.persistence.dom.RSEDOMImporter.getSubSystemConfiguration(RSEDOMImporter.java:491)
at org.eclipse.rse.internal.persistence.dom.RSEDOMImporter.restoreFilterPool(RSEDOMImporter.java:362)
at org.eclipse.rse.internal.persistence.dom.RSEDOMImporter.restoreProfile(RSEDOMImporter.java:90)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.load(RSEPersistenceManager.java:393)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.loadProfiles(RSEPersistenceManager.java:373)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.restoreProfiles(RSEPersistenceManager.java:232)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.restoreProfiles(RSEPersistenceManager.java:218)
at org.eclipse.rse.internal.core.model.SystemProfileManager.getDefault(SystemProfileManager.java:55)
at org.eclipse.rse.core.model.SystemStartHere.getSystemProfileManager(SystemStartHere.java:180)
at org.eclipse.rse.ui.RSEUIPlugin$InitRSEJob.run(RSEUIPlugin.java:98)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Traceback from error 'Exception in createConnection for 127.0.0.1':

java.lang.NullPointerException
at org.eclipse.rse.internal.persistence.PropertyFileProvider.getSaveJob(PropertyFileProvider.java:151)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.save(RSEPersistenceManager.java:423)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.commitProfile(RSEPersistenceManager.java:138)
at org.eclipse.rse.internal.core.model.SystemProfile.commit(SystemProfile.java:216)
at org.eclipse.rse.internal.core.model.SystemHostPool.commit(SystemHostPool.java:612)
at org.eclipse.rse.internal.core.model.SystemHostPool.commit(SystemHostPool.java:621)
at org.eclipse.rse.internal.core.model.SystemHostPool.updateHost(SystemHostPool.java:254)
at org.eclipse.rse.internal.core.model.SystemHostPool.createHost(SystemHostPool.java:208)
at org.eclipse.rse.ui.internal.model.SystemRegistry.createHost(SystemRegistry.java:1770)
at org.eclipse.rse.ui.internal.model.SystemRegistry.createHost(SystemRegistry.java:1719)
at org.eclipse.rse.ui.internal.model.SystemRegistry.createHost(SystemRegistry.java:2040)
at org.eclipse.rse.ui.internal.model.SystemRegistry.createHost(SystemRegistry.java:2011)
at org.eclipse.rse.internal.core.model.SystemProfile.createHost(SystemProfile.java:89)
at org.eclipse.rse.internal.persistence.dom.RSEDOMImporter.restoreHost(RSEDOMImporter.java:125)
at org.eclipse.rse.internal.persistence.dom.RSEDOMImporter.restoreProfile(RSEDOMImporter.java:88)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.load(RSEPersistenceManager.java:393)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.loadProfiles(RSEPersistenceManager.java:373)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.restoreProfiles(RSEPersistenceManager.java:232)
at org.eclipse.rse.internal.persistence.RSEPersistenceManager.restoreProfiles(RSEPersistenceManager.java:218)
at org.eclipse.rse.internal.core.model.SystemProfileManager.getDefault(SystemProfileManager.java:55)
at org.eclipse.rse.core.model.SystemStartHere.getSystemProfileManager(SystemStartHere.java:180)
at org.eclipse.rse.ui.RSEUIPlugin$InitRSEJob.run(RSEUIPlugin.java:98)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Comment 7 Greg Watson 2007-07-23 15:56:33 EDT

Adding the getAnchor() call does seem to prevent the NPE. However now restoring RSE is failing at about the same frequency that the NPE was occurring.

I'm using the following code:

	while (!RSECorePlugin.getThePersistenceManager().isRestoreComplete() && timeout < 5) {
			System.out.println("waiting for restore...");
			try {
				Thread.sleep(1000);
				timeout++;
			} catch (InterruptedException e) {
			}
		}

Even after 5 timeouts, RSE still has not restored.

Comment 8 Martin Oberhuber 2007-07-23 19:09:54 EDT

(In reply to comment #7)
> Adding the getAnchor() call does seem to prevent the NPE. However now
> restoring RSE is failing at about the same frequency that the NPE was
> occurring.

What do you mean by "same frequency" ? Does it ever work?
Do you see any other errors logged e.g. "OSGI ..bundle activation..gave up after waiting 5000 msec"...?
Are you on HEAD of RSE for all plugins or working off a released build?

Thanks

Comment 9 Greg Watson 2007-07-24 11:50:49 EDT

(In reply to comment #8)
> (In reply to comment #7)
> > Adding the getAnchor() call does seem to prevent the NPE. However now
> > restoring RSE is failing at about the same frequency that the NPE was
> > occurring.
> 
> What do you mean by "same frequency" ? Does it ever work?

Yes, it works about half of the time, which is pretty weird, but I guess indicative of a race condition. I was seeing the NPE about half of the time also, but the change to getAnchor() seems to have solved that.

> Do you see any other errors logged e.g. "OSGI ..bundle activation..gave up
> after waiting 5000 msec"...?

Nothing is shown in the error log.

> Are you on HEAD of RSE for all plugins or working off a released build?

I'm using HEAD as of yesterday.

Comment 10 Eclipse Webmaster 2007-07-29 09:23:15 EDT

Changing OS from Mac OS to Mac OS X as per bug 185991

Comment 11 Martin Oberhuber 2007-08-06 13:04:45 EDT

It turns out that the method for waiting for RSE to initialize as outlined in comment #7, is not quite correct. Here is better code:


Job[] jobs = Job.getJobManager().find(null);
for(int i=0; i<jobs.length; i++) {
    if ("Initialize RSE".equals(jobs[i].getName())) { //$NON-NLS-1$
	jobs[i].join();
	break;
    }
}


In case this runs during system initialization, it finds the InitRSEJob and waits for its completion. This does slightly more than just waiting for the persistence manager, so it's more robust; we are also using this in our unit tests, as per bug #198956.

Please try using this code, and I'm confident the problem should be gone.

Comment 12 lars gersmann 2007-08-17 08:06:26 EDT

(In reply to comment #11)
> It turns out that the method for waiting for RSE to initialize as outlined in
> comment #7, is not quite correct. Here is better code:
> 
> 
> Job[] jobs = Job.getJobManager().find(null);
> for(int i=0; i<jobs.length; i++) {
>     if ("Initialize RSE".equals(jobs[i].getName())) { //$NON-NLS-1$
>         jobs[i].join();
>         break;
>     }
> }
> 

strange thing - this code produces *sometimes* a deadlock (the join method call to be concrete). i can definitely reproduce the deadlock. just execute this code inside a Eclipse build thread (in my case an incremetal builder). 

is that issue relying to swt threading ? 

Comment 13 Martin Oberhuber 2007-08-17 08:19:11 EDT

(In reply to comment #12)
> to be concrete). i can definitely reproduce the deadlock. just execute this
> code inside a Eclipse build thread (in my case an incremetal builder). 

It's quite natural that this can produce a deadlock. You're waiting for another thread, so if you own any resources that are needed by that other thread you're deadlocking.

In other words, your thread apparently owns some resources which are needed by the InitRSEJob to complete. Having it deadlock "sometimes" may depend on the time when your thread starts locking the resources: If InitRSEJob is already done with them at the time you grab them, you'll not deadlock.

Since you mention the build thread, I suppose that your thread owns an ISchedulingRule (resource, project, ...) which the InitRSEJob needs to complete.

Note that this deadlock is independent of the method you use for waiting for the InitRSEJob to complete. You must ensure that you free the resources it needs, before you start waiting for it. You'll need to debug this yourself, to understand what resources you are holding on to. To debug it, you can 

a) Launch you app in debugger - suspend everything when it deadlocks - look
   at what resource the InitRSEJob is trying to acquire
b) Launch you app from commandline on UNIX - do kill -SIGQUIT (java-pid)
   to get a thread dump to stdout
c) Launch you app with -vmargs -Dcom.sun.management.jmxremote
   Then, start jconsole, attach to the app, look at the thread dump
d) With your app deadlocking, webstart this app to get a thread dump:
   http://www.adaptj.com/root/main/download

Comment 14 Martin Oberhuber 2007-09-03 10:51:40 EDT

*** Bug 202040 has been marked as a duplicate of this bug. ***

Comment 15 Martin Oberhuber 2007-09-03 10:56:19 EDT

See also the code in bug 202040 comment 1 for properly waiting for the RSE model to restore. If this still doesn't help, try activating the RSEUIPlugin already in your Activator.start() method:

public class MyPlugin extends plugin {
  /* ... */
  public void start(BundleContext context) throws Exception {
    //Activate RSE and load profiles eagerly
    RSEUIPlugin.getDefault();
  }
}

Comment 16 David Dykstal 2007-09-10 21:58:03 EDT

I am closing this bug as it appears to be fixed by changing the client code. If there are still problems please reopen and add the appropriate description. Thanks!

Comment 17 Martin Oberhuber 2007-10-03 15:19:47 EDT

*** Bug 205338 has been marked as a duplicate of this bug. ***