Description Stefan Oehme 2016-03-16 13:59:32 EDT

Let's take this (braindead) example of a job that runs fast, but produces a lot of "subTask()" calls on it's progress monitor:

WorkspaceJob job = new WorkspaceJob("Doing stuff") {
    @Override
    public IStatus runInWorkspace(IProgressMonitor monitor) throws CoreException {
        monitor.beginTask("Doing stuff", 5000);
        try {
            //wait until dialog pops up
            Thread.sleep(1000);
        } catch (InterruptedException e) {
        }
        for (int i = 0; i < 5000; i++) {
            monitor.subTask("Doing step " + i);
            monitor.worked(1);
        }
        monitor.done();
        return Status.OK_STATUS;
    }
};
job.setUser(true);
job.schedule();

A progress dialog pops up (as expected since we have the 1s wait at the beginning) and starts displaying every single message. The logic inside the job has already finished executing, but the dialog stays open for a long time, catching up with all the messages.

If I click "Run in Background", it is minimized to the progress view and finishes immediately, because the progress view does not have this blocking behavior.

The real use case is importing projects in Buildship. Usually it goes very fast, so the progress logging becomes a bottleneck. Of course we could log less fine grained. But sometimes the user has a mistake in his build script which makes some subtasks take a very long time. In such a case the user wants to know where the import is hanging.

We are currently working around this with a rate limiter in our progress reporting, but I think this should be fixed in the platform.