Description John Arthorne 2005-11-29 15:30:15 EST

Build: I20051129

I have been noticing that when an autobuild is needed on startup, it frequently takes a very long time to run, and often stops and restarts several times.  The most painful case is on startup of a self-hosting workspace immediately after upgrading to a new build. Sometimes this takes several minutes for me on a large workspace.

I added some instrumentation to the build manager to track this down, and it turns out the classpath initialization performs many small workspace operations without combining it into a single IWorkspaceRunnable.  A typical sequence of events seems to be:

1) Classpath of project 1 is being initialized.
2) Project.setDescription is called when the dynamic project references are set.
3) An autobuild starts
4) Classpath of project 2 is initialized
5) Project.setDescription is called.  The autobuild is told to quit and the caller waits until autobuild completes.
6) Another autobuild starts.

I believe all these intermediate autobuilds will be wasted because the project classpaths aren't even initialized yet. I.e., there is no point starting an autobuild until all projects in the workspace have their classpaths initialized. Even worse, if the dynamic classpaths have not been set, then the build order might be wrong, and these early builds might be causing build state to be discarded because pre-req projects have not yet been built.

 This can be solved by putting an IWorkspace.run() lower in the stack during classpath initialization, but I don't know the code well enough to suggest what is the best place.  Note that you can batch changes without obtaining any scheduling rules by using IWorkspace.run(IWorkspaceRunnable, null, flags, pm) - this would avoid the risk of introducing deadlocks or concurrency problems in this delicate code.

I will attach a console log from my startup today with my build manager instrumentation turned on.  It creates and logs a fake "Exception" each time the autobuild is interrupted.