Decorators don't always update, fails to commit modified files

[kgeri]

I'm working on a lot of (about 19) maven projects, and I've noticed that the status computation, and the display of decorator overlays is taking up a lot of CPU, and sometimes it doesn't work at all.

What's worse though, is that when decorators fail to appear (eg. on a recently changed file), I can't even commit that file, because it says "Nothing to commit".

Environment is Eclipse Helios SR1, Windows XP.
I see the following stacktraces in the eclipse error logs (cropped, tell me if you need the full logs):

ERROR Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench".
java.lang.NullPointerException
at org.vcs.bazaar.eclipse.internal.core.model.LocalBranch.isBound(LocalBranch.java:149)
at org.vcs.bazaar.eclipse.ui.actions.UnBindAction.isEnabledByType(UnBindAction.java:46)
at org.vcs.bazaar.eclipse.ui.actions.WorkspaceAction.isEnabled(WorkspaceAction.java:58)
at org.vcs.bazaar.eclipse.ui.internal.TeamAction.setActionEnablement(TeamAction.java:315)
at org.vcs.bazaar.eclipse.ui.actions.BzrAction.setActionEnablement(BzrAction.java:86)
at org.vcs.bazaar.eclipse.ui.internal.TeamAction.selectionChanged(TeamAction.java:298)
at org.eclipse.ui.internal.PluginAction.refreshEnablement(PluginAction.java:206)
...

ERROR Unexpected error while decorating: <project name>
java.lang.RuntimeException: org.vcs.bazaar.eclipse.internal.core.BazaarException: A unexpected error ocurred
at org.vcs.bazaar.eclipse.internal.core.BazaarException.makeUnChecked(BazaarException.java:126)
at org.vcs.bazaar.eclipse.internal.core.model.ProjectBranch.getNick(ProjectBranch.java:79)
at org.vcs.bazaar.eclipse.ui.decorator.BazaarLightweightDecorator.decorateByType(BazaarLightweightDecorator.java:125)
at org.vcs.bazaar.eclipse.ui.decorator.BazaarLightweightDecorator.decorate(BazaarLightweightDecorator.java:94)
at org.vcs.bazaar.eclipse.ui.decorator.BazaarLightweightDecorator.decorate(BazaarLightweightDecorator.java:83)
at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:263)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:81)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:365)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:347)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:371)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:331)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.vcs.bazaar.eclipse.internal.core.BazaarException: A unexpected error ocurred
at org.vcs.bazaar.eclipse.internal.core.BazaarException.wrapException(BazaarException.java:118)
at org.vcs.bazaar.eclipse.core.commands.NickCommand.run(NickCommand.java:34)
at org.vcs.bazaar.eclipse.internal.core.model.ProjectBranch.getNick(ProjectBranch.java:76)
... 11 more
Caused by: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: unknown command "D:\programs\Bazaar\bzr.exe"
at org.vcs.bazaar.client.xmlrpc.internal.XMLRPCCommandRunner.access$100(XMLRPCCommandRunner.java:28)
at org.vcs.bazaar.client.xmlrpc.internal.XMLRPCCommandRunner$1.internalExecute(XMLRPCCommandRunner.java:129)
at org.vcs.bazaar.client.xmlrpc.internal.XMLRPCCommandRunner$1.internalExecute(XMLRPCCommandRunner.java:128)
at org.vcs.bazaar.client.xmlrpc.internal.XMLRPCCommandRunner$SafeXmlRPCCall.execute(XMLRPCCommandRunner.java:185)
at org.vcs.bazaar.client.xmlrpc.internal.XMLRPCCommandRunner.runCommand(XMLRPCCommandRunner.java:126)
at org.vcs.bazaar.client.commandline.internal.Command.execute(Command.java:82)
at org.vcs.bazaar.client.commandline.CommandLineClient.run(CommandLineClient.java:623)
at org.vcs.bazaar.client.commandline.CommandLineClient.run(CommandLineClient.java:617)
at org.vcs.bazaar.client.commandline.CommandLineClient.nick(CommandLineClient.java:330)
at org.vcs.bazaar.eclipse.core.commands.NickCommand.run(NickCommand.java:31)
at org.vcs.bazaar.eclipse.internal.core.model.ProjectBranch.getNick(ProjectBranch.java:76)
at org.vcs.bazaar.eclipse.ui.decorator.BazaarLightweightDecorator.decorateByType(BazaarLightweightDecorator.java:125)
at org.vcs.bazaar.eclipse.ui.decorator.BazaarLightweightDecorator.decorate(BazaarLightweightDecorator.java:94)
at org.vcs.bazaar.eclipse.ui.decorator.BazaarLightweightDecorator.decorate(BazaarLightweightDecorator.java:83)
at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:263)
...

WARNING While loading class "org.vcs.bazaar.eclipse.core.listeners.FileModificationManager$1", thread "Thread[Worker-1,5,main]" timed out waiting (5000ms) for thread "Thread[Worker-2,5,main]" to finish starting bundle "org.vcs.bazaar.eclipse.core_1.1.1.210 [375]". To avoid deadlock, thread "Thread[Worker-1,5,main]" is proceeding but "org.vcs.bazaar.eclipse.core.listeners.FileModificationManager$1" may not be fully initialized.
org.osgi.framework.BundleException: State change in progress for bundle "reference:file:plugins/org.vcs.bazaar.eclipse.core_1.1.1.210.jar" by thread "Worker-2".
at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1077)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:282)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417)
at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at org.vcs.bazaar.eclipse.core.listeners.FileModificationManager.resourceChanged(FileModificationManager.java:53)
at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:291)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:327)
at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1181)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1984)
at org.eclipse.core.internal.events.NotificationManager$NotifyJob.run(NotificationManager.java:40)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
... 24 more
Root exception:
org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1077)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:282)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417)
at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at org.vcs.bazaar.eclipse.core.listeners.FileModificationManager.resourceChanged(FileModificationManager.java:53)
at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:291)
...

[kgeri (kiss-gergely)]

Maybe this info is also useful: I'm running two or more eclipses at work, yet I always see only one bzr.exe started by one of them.

[kgeri (kiss-gergely)]

Okay, after some digging it seems I've found a bug at org.vcs.bazaar.eclipse.core.commands.LsCommand:43 (and 45).
It says:

paths = client.ls(resource.getProject().getLocation().toFile() ...

But should be:

paths = client.ls(resource.getLocation().toFile()

Which means that every list operation (=status update) starts from the root, no matter which resource I select. I also found that every status update is fully _recursive_, and the simple check of whether a single resource is version controlled or not means a status update, if it's not in the cache. And finally: there is a cache, but it removes its elements after 5 seconds :)

Add these together and now I see why the right-click menu is so slow for our project with 20k+ files.

I'll fix these in the status-ng branch, but please tell me if I overlooked something.

[Adrian Wilkins (adrian-wilkins)]

The "two Eclipse instances but only 1 bzr instance" thing is normal unless you specifically configure a different XMLRPC port in your preferences - the second instance wouldn't start because it can't bind the default XMLRPC port. It should still (AFAIK) work just fine though, because the second instance will connect to the bzr instance from the first Eclipse.

[Maarten Kossen (mpkossen)]

Is there an update on this? I see a fix is pending review? It would be more than welcome here. I've got a project with over 100k files and currently it's a real pain to right-click or add something.

[kgeri (kiss-gergely)]

Maarten: unfortunately Guillermo is hard to reach, but I've committed a patch in the status-ng branch which makes it faster (https://code.launchpad.net/~kiss-gergely/bzr-eclipse/status-ng). You may check that out and build the plugin with maven, but as far as I can tell, status handling would need a major refactor, so I suggest you use Bazaar Explorer and/or the command line (yes, they are a lot more inconvenient, but they work well for large projects).

[Alexander Taler (alex-idereal)]

Verified that the exception is now handled, so the problem should be resolved.