Community
Participate
Working Groups
I20070517-1700 Given new workspace 1. Past: package b; public class E01{} into empty package explorer 2. In PE select E01 3. Past package b; public class E02{} Is: E02 does not appear in PE Should: appear and be selected
Delta after step 1: Java Model[*]: {CHILDREN} _pasted_code_[+]: {} [Working copy] E01.java[*]: {AST AFFECTED} Delta after step 3: Java Model[*]: {CHILDREN} _pasted_code_[*]: {CHILDREN} src[*]: {CHILDREN} b[+]: {} [Working copy] E02.java[*]: {AST AFFECTED} The problem seems to be that 'b' is marked as addition, but it already exists at time and the package explorer is skipping that delta. The delta should mark 'b' as changed and 'E02' as added. Moving to jdt.core
Cannot reproduce. After step 3, I get: FIRING POST_CHANGE Delta [Thread[main,6,main]]: Java Model[*]: {CHILDREN} _pasted_code_[*]: {CHILDREN} src[*]: {CHILDREN} b[*]: {CHILDREN} [Working copy] E02.java[+]: {} and the PE correctly shows E02.
It only works with a fresh workspace and exactly the provided steps. I guess with your delta you can also not reproduce the initial bug.
Yep, I started with a fresh workspace and followed the steps given in comment 0
Note with 3.2, you had to create a Java project before step 1. After creating this Java project, and following the given steps, E02 appeared in the PE.
I finally was able to reproduce the problem on a slow machine. On step 1, I'm seeing the project being created in the 'main' thread, but the corresponding resource delta being reported in a 'Worker-2' thread. This is what's causing the JDT/Core delta processor to fail. Thread [Worker-2] (Suspended (breakpoint at line 368 in DeltaProcessingState)) DeltaProcessingState.resourceChanged(IResourceChangeEvent) line: 368 NotificationManager$2.run() line: 282 SafeRunner.run(ISafeRunnable) line: 37 NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 276 NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 148 Workspace.broadcastPostChange() line: 311 Workspace.endOperation(ISchedulingRule, boolean, IProgressMonitor) line: 1018 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 1806 NotificationManager$NotifyJob.run(IProgressMonitor) line: 39 Worker.run() line: 55 John, can't we assume that the delta is going to be reported in the same thread that modified the resource any longer ? Or would that be a bug in Platform/Resources ?
> John, can't we assume that the delta is going to be reported in the same > thread that modified the resource any longer ? It has been like this since Eclipse 3.0. When two threads are modifying the workspace concurrently, a POST_CHANGE event could occur in either thread. That delta will contain all changes since the last POST_CHANGE event, regardless of what thread the changes occurred in. FWIW, here is what the resource delta looked like after step 1: /[*]: {} /_pasted_code_[+]: {OPEN} /_pasted_code_/.classpath[+]: {} /_pasted_code_/.project[+]: {} /_pasted_code_/.settings[+]: {} /_pasted_code_/.settings/org.eclipse.jdt.core.prefs[+]: {} /_pasted_code_/src[+]: {} /_pasted_code_/src/b[+]: {} /_pasted_code_/src/b/E01.java[+]: {} And here is the resource delta after step 3: /[*]: {} /_pasted_code_[*]: {} /_pasted_code_/src[*]: {} /_pasted_code_/src/b[*]: {} /_pasted_code_/src/b/E02.java[+]: {} These deltas look correct.
Indeed the delta looks correct, but it is notified in the NotificationManager thread (I'm not sure what this notification manager is), it is NOT notified in the 'main' thread where the change occurred. Looking at the doc, I don't see anything that says that a resource delta could be notified in a different thread than the thread where the modification occurred.
There is also nothing in the doc that says events do occur in the same thread as the modification <g>. I seem to recall a long bugzilla discussion about this in the past, but I can't find it now. There is a trade-off here: if we guaranteed that events occurred in the same thread, then we would not be able to guarantee that events are received in the same order in which the changes occurred. It would also be expensive to track the thread that each change occurred in.
I wasn't aware either of notifications being able to occur in a different thread, at least for post-change (pre/post-build may occur elsewhere due to background autobuild).
I wasn't aware of this either. This is scary since we always assumed that the resource event would occur in the same thread as where the modification occurred. I suspect we are not the only ones to make this assumption. I entered bug 189722 against JDT/Core to remove this assumption. Of course this is too big of a change for RC3, and it will have to wait until after 3.3.
Created attachment 69095 [details] Possible workaround The workaround consists in ensuring that posted Java deltas are fired after the batch operation has finished
I'm surprised this hasn't bitten you earlier, since it has been like this for three years. I expect it to be quite common for the notifications to happen in a different thread. This happens when there is an intermediate resource change event during a long operation, or when there are multiple resource changes happening concurrently in different threads (resource change will be broadcast at the end of the operation that finishes last).
Our delta processing has also been relying on it for the same amount of time (years)... scary indeed.
Re: patch from Jerome
Re: patch from Jerome Isn't there a risk that a client may get 2 deltas for the same Java model operation now in 2 different threads ? (one for the Java model delta, one for the converted rsc delta).
*** Bug 190858 has been marked as a duplicate of this bug. ***
DeltaProcessor needs to be rewritten to not assume that the resource delta is sent in the same thread as where the resource was modified.
*** Bug 186858 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 189722 ***
