Comment 1 Moritz Eysholdt 2015-02-10 04:38:14 EST

Same with org.eclipse.xtend.core.tests

Comment 2 Sebastian Zarnekow 2015-02-10 05:36:08 EST

I also observe many interrupted builds also on a machine that's otherwise idle

Comment 3 Moritz Eysholdt 2015-02-10 09:04:47 EST

This is the loop:

1. IncrementalProjectBuilder.isInterrupted() is true, so 
  XtextBuilder.build(int, Map, IProgressMonitor) throws an 
  OperationCanceledException.

2. BuildManager.getSafeRunnable().new ISafeRunnable() {...}.handleException(Throwable)
  catches the exception and calls
  currentBuilder.forgetLastBuiltState();
  
3. The AtoBuildJob schedules itself again in
  AutoBuildJob.canceled()
  it an OperationCanceledException is thrown and the job is marked as interrupted.

4. Because the LastBuildState was forgotten, the next build is a full build.

5. At some point, the build is marked as ‘interrupted’ again because 
  Job.isBlocking() returns true.


Long story short, something keeps interrupting my AutoBuilds so that the next build is a full build.

Comment 4 Moritz Eysholdt 2015-02-10 09:08:56 EST

On my Machine, it's always the Job 
ThreadJob(Updating Git status for repository org.eclipse.xtext(691),[R/])
that causes the AutoBuild to feel like it's blocking something.

Comment 5 Moritz Eysholdt 2015-02-10 09:21:02 EST

The EGit Job is a thread-job, i.e. it's not a subclass of Job, but implicitly became a job by calling JobManager.beginRule().

This is its stack trace:

Thread [Worker-72] (Suspended)	
	waiting for: Object  (id=998)	
	Object.wait(long) line: not available [native method]	
	Object.wait() line: 502	
	ThreadJob.waitForRun(ThreadJob, IProgressMonitor, InternalJob, Thread) line: 270	
	ThreadJob.joinRun(ThreadJob, IProgressMonitor) line: 197	
	ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 92	
	JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 306	
	IndexDiffCacheEntry.waitForWorkspaceLock(IProgressMonitor) line: 359	
	IndexDiffCacheEntry.access$3(IndexDiffCacheEntry, IProgressMonitor) line: 351	
	IndexDiffCacheEntry$5.updateIndexDiff(Collection<String>, Collection<IResource>, IProgressMonitor) line: 408	
	IndexDiffCacheEntry$5(IndexDiffUpdateJob).run(IProgressMonitor) line: 74	
	Worker.run() line: 55

Comment 6 Eclipse Genie 2015-02-10 09:52:59 EST

New Gerrit change created: https://git.eclipse.org/r/41526

Comment 7 Eclipse Genie 2015-02-10 11:15:55 EST

Gerrit change https://git.eclipse.org/r/41526 was merged to [master].
Commit: http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=33a97a72a61e3f6749b2c27517127db0c9d38281

Comment 8 Moritz Eysholdt 2015-02-10 11:24:24 EST

fixed.

Comment 9 Jan Koehnlein 2015-02-17 05:17:39 EST

Changed code a bit to make it clearer that we are exiting the build on interruption.

Comment 10 Sven Efftinge 2015-07-30 17:10:26 EDT

I'm seeing this on my machine atm.

Comment 11 Sven Efftinge 2015-07-31 05:47:14 EDT

The egit job (IndexDiffUpdateJob) still frequently interrupts our builds, as it is not super regularly scheduled (every ten seconds, see 

org.eclipse.egit.ui.Activator.RepositoryChangeScanner.REPO_SCAN_INTERVAL

The job itself doesn't have a scheduling rule, but it calls 

org.eclipse.egit.core.internal.indexdiff.IndexDiffCacheEntry.waitForWorkspaceLock(IProgressMonitor)

	private void waitForWorkspaceLock(IProgressMonitor monitor) {
		// Wait for the workspace lock to avoid starting the calculation
		// of an IndexDiff while the workspace changes (e.g. due to a
		// branch switch).
		// The index diff calculation jobs do not lock the workspace
		// during execution to avoid blocking the workspace.
		IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
		try {
			Job.getJobManager().beginRule(root, monitor);
		} catch (OperationCanceledException e) {
			return;
		} finally {
			Job.getJobManager().endRule(root);
		}
	}

All non-system jobs with the same scheduling rule will make the AutoBuildJob interrupted. I think the cause is, that the scheduled job is not a system job.
Another effect of a system job is that it is not shown in the UI.

I have filed a bugzilla for egit about this : https://bugs.eclipse.org/bugs/show_bug.cgi?id=474003

For the time being we need to somehow deal with this.

Comment 12 Eclipse Genie 2015-07-31 11:21:15 EDT

GitHub Pull Request 443 created by [svenefftinge]
https://github.com/eclipse/xtext/pull/443

Comment 13 Sven Efftinge 2015-07-31 15:29:01 EDT

merged

Comment 14 Eclipse Webmaster 2017-10-31 10:48:05 EDT

Requested via bug 522520.

-M.

Comment 15 Eclipse Webmaster 2017-10-31 10:59:07 EDT

Requested via bug 522520.

-M.

Comment 16 Ed Willink 2017-12-29 13:24:04 EST

I don't understand how this can be a fix.

If there is a problem with an EGIT job, then where is the EGIT bug awaiting a fix?

If there is not a problem with an EGIT job, then why is Xtext modifying EGIT jobs?

Given the outstanding Xtext builder/indexer issues this kind of fudge seems like a recipe for making a bad situation worse, if not today, after an EGIT evolution.

Comment 17 Christian Dietrich 2017-12-29 13:44:24 EST

please discuss at https://github.com/eclipse/xtext-eclipse/issues/251

Comment 18 Ed Willink 2017-12-29 15:31:04 EST

(In reply to Christian Dietrich from comment #17)
> please discuss at https://github.com/eclipse/xtext-eclipse/issues/251

I don't see why.

Bugzilla is the EF bug reporting network. Xtext is an EF supported project.

XtextBuilder.java has the text:

  * This is a fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=459525

This bug had no reference to anything else.

Comment 19 Christian Dietrich 2017-12-29 15:48:51 EST

xtext uses github issues.
bugzilla is legacy.
it just there cause auf aeri and cause there is no editable but no new issues mode afaik.
nobody reads or care about bugzilla. 
i am just nice answering you here.

https://github.com/eclipse/xtext-eclipse/issues/251
is about getting rid about this workaround.
discussing the same thing at 20 different places makes no sense to me.