Performance problems with Subversive 1.0.3, RAD and big proj

[alessio.spadaro]

Hello,
we're using Subversive 1.0.3 with IBM Rational Application Developer 6.0.x on a big project (33k files total on projects working copy) on WinXP workstations. Most files are on one project.
The initial checkout took 45 minutes, with the server sleeping all the time (but this has een solved by distribuiting a zipped version for a quick start).
Each file save operation on the big project take a long time (20 sec) at least, freezing RAD in the worst case (we have 20 workstations, 12 of them are in the worst condition). On file save we can see both javaw.exe and system.exe taking a lot of cpu for a long time.
Detaching the projects make RAD work fine.
I read many post on the subject, but all references older versions of subversive. Tricks like disabling features of the ide, disk indexing, ave been tried with no results.
I see that a first build of 1.0.4 was done: maybe using this can help?

We cannot switch to the 1.1.x because RAD is eclipse 3.0.2-based

Thanks in advance

[alessio.spadaro]

It wasn't the plugin, sorry.

Regards

[alessio.spadaro]

Well, the problem was found in the realtime scan of the antivirus running on the workstations. The strange thing is that the very same workstations works well with, for example, Eclipse 3.2 (and, i think RAD 7.0) and the 1.1.x plugin.
Do you have any idea about this? Will the 1.0.4 (that i see was built recently) will have any of the improvement found on the 1.1.x?

Regards

[alessio.spadaro]

I just tried subversive 1.0.4 under RAD 6.0 to see if it solves the problem, but installing it causes the contextual menu to stop working in the java perspective. Uninstalling it and reinstalling 1.0.3 solve the contextual menu problem.
Is there anything i could do to check where the problem is?

Regards

[Alexander Gurov]

Dear Alessio,

I tried Subversive 1.0.4 (which we published today) with the Eclipse 3.0.1, Eclipse 3.0.2, Eclipse 3.1.1 versions and found no problems with the context menu.
It is possible that you tried internal testing build from our repository (one of test builds contains same problem like you described)? If so, please try the 1.0.4 build which we published toady.

Also regarding performance issues: yes, the 1.0.4 build provides performance imporvements in compare to the 1.0.3.

[alessio.spadaro]

Hi,
updating to the official 1.0.4 yield the same result.
All seems to work, and seems much faster than 1.0.3, but right-clicking on java perspectives causes these exceptions to be thrown (from .metadata/.log):

!ENTRY org.eclipse.ui 4 4 apr 03, 2007 12:54:08.187
!MESSAGE Unhandled event loop exception

!ENTRY org.eclipse.ui 4 0 apr 03, 2007 12:54:08.203
!MESSAGE java.lang.NullPointerException
!STACK 0
java.lang.NullPointerException
at org.polarion.team.svn.ui.action.AbstractSVNTeamAction.getSelectedResources(Unknown Source)
at org.polarion.team.svn.ui.action.AbstractLocalTeamAction.checkSelection(Unknown Source)
at org.polarion.team.svn.ui.action.AbstractSVNTeamAction.selectionChanged(Unknown Source)
at org.eclipse.ui.internal.PluginAction.refreshEnablement(Unknown Source)
at org.eclipse.ui.internal.PluginAction.selectionChanged(Unknown Source)
at org.eclipse.ui.internal.ObjectActionContributor.contributeObjectActions(Unknown Source)
at org.eclipse.ui.internal.ObjectActionContributorManager.contributeObjectActions(Unknown Source)
at org.eclipse.ui.internal.PopupMenuExtender.addObjectActions(Unknown Source)
at org.eclipse.ui.internal.PopupMenuExtender.menuAboutToShow(Unknown Source)
at org.eclipse.jface.action.MenuManager.fireAboutToShow(Unknown Source)
at org.eclipse.jface.action.MenuManager.handleAboutToShow(Unknown Source)
at org.eclipse.jface.action.MenuManager.access$0(Unknown Source)
at org.eclipse.jface.action.MenuManager$2.menuShown(Unknown Source)
at org.eclipse.swt.widgets.TypedListener.handleEvent(Unknown Source)
at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Control.WM_INITMENUPOPUP(Unknown Source)
at org.eclipse.swt.widgets.Control.windowProc(Unknown Source)
at org.eclipse.swt.widgets.Decorations.windowProc(Unknown Source)
at org.eclipse.swt.widgets.Display.windowProc(Unknown Source)
at org.eclipse.swt.internal.win32.OS.TrackPopupMenu(Native Method)
at org.eclipse.swt.widgets.Menu._setVisible(Unknown Source)
at org.eclipse.swt.widgets.Display.runPopups(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at org.eclipse.ui.internal.Workbench.runEventLoop(Unknown Source)
at org.eclipse.ui.internal.Workbench.runUI(Unknown Source)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Unknown Source)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(Unknown Source)
at org.eclipse.ui.internal.ide.IDEApplication.run(Unknown Source)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
at java.lang.reflect.Method.invoke(Method.java:391)
at org.eclipse.core.launcher.Main.basicRun(Main.java:185)
at org.eclipse.core.launcher.Main.run(Main.java:704)
at org.eclipse.core.launcher.Main.main(Main.java:688)

Contextual menu on svn perspectives works fine.

Regards,
Alessio

[Alexander Gurov]

Dear Alessio,

Thank you for your effort. We checked the stack trace and found a place where NPE can happen. Now corrected 1.0.4 is loaded back to the update site. Unfortunatelly we have no access to the RAD 6.0 and we cannot check our changes. Could you please check if the fix works for you?

Thank you in advance and sorry for inconvenience.

[alessio.spadaro]

Hi,
i'm getting the very sme exception after the update. The strange thing is that at first RAD didn't see the available upgrade. I uninstalled the 1.0.4 completely and then upgrade from 1.0.3 from the update site, so i think the archives have been properly updated.
The exception is identical, do you have any suggestion to be sure i upgraded it correctly?

Regards,
Alessio

[alessio.spadaro]

Maybe i was too early.. i see another change on the repository.
I'll try to update from the latest local update site.

[alessio.spadaro]

I confirm, theissue is still here.

Regards,
Alessio

[Alexander Gurov]

Dear Alessio,

It is possible that you works through the proxy? If so, could you please switch off the proxy and try to download local update site?
You can check that it is really correct build if the local update site contains separate support for JDT (the feature is called JDT Ignore Extensions (Optional) and it is placed in the "Subversive" category of the update site).

[alessio.spadaro]

I double-checked and reinstalled from scratch (the jdt feature is present).
The situation now is this:
- workspaces already bound to a subversion server give the same exception
- newly-created workspaces fail to give a correct contextual menu: all resources give a menu with only a few choiches (as if the file was a simple file) on java resources on the first run (even if they are corretly decorated with svn informations)
- reopening the new workspace the resources are corretly decorated, but contextual menus are shown as if the resources were not under revision control.

Regards,
Alessio

[Alexander Gurov]

Dear Alessio,

We made another changes related to the problem and reloaded the update site. The code which relates to stack trace looks like:

Code: Select all

protected IResource []getSelectedResources() {
   IProduct product = Platform.getProduct();
   if (product != null) {
      String description = product.getDescription();
      if (description != null) {
         int idx = description.indexOf("Version:");
         if (idx != -1) {
            idx += "Version:".length() + 1;
            if (idx + 5 < description.length()) {
               description = description.substring(idx, idx + 5);
               if ("3.2.0".compareTo(description) > 0) {
                  return (IResource [])getSelectedResources(IResource.class);
               }
            }
         }
      }
   }
   return super.getSelectedResources();
}


So, now the code cannot throw NPE in any case and I really hope that the problem will be avoided. Could you please try 1.0.4 once again?

[alessio.spadaro]

Now it's working.
I had to uninstall all plugins (both 1.0.3 and 1.0.4), phisically remove all folders from RAD installation directory (uninstall them didn't delete from disk, as said on rad's interface) and then install 1.0.4.

It also seems much, much faster

Thanks a lot for your support and for the great work.

Regards,
Alessio