Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 329333 - [Backport] Concurrent access to file while decorating
Summary: [Backport] Concurrent access to file while decorating
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.6.2   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 327192
Blocks:
  Show dependency tree
 
Reported: 2010-11-03 07:51 EDT by Szymon Ptaszkiewicz CLA
Modified: 2011-01-20 11:02 EST (History)
6 users (show)

See Also:

Attachments
Patch v.0.1 (1.84 KB, patch)
2010-11-03 12:03 EDT, Szymon Ptaszkiewicz CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Szymon Ptaszkiewicz CLA 2010-11-03 07:51:38 EDT 
Bug cloned to track potential release into 3.6.2.

+++ This bug was initially created as a clone of Bug #327192 +++

The issue came out while working on bug 301223. The problem is that during project set import decorating thread and importing thread are both trying to use the same file. Decorating thread is calling file.getContentDescription() and importing thread is trying to delete this file to make space for incoming file from repository. The file is open because of decorator so delete operation is not successful which results in error during import. Delete operation uses scheduling rule but decorator is not. There should be added simple scheduling rule to decorate operation to prevent concurrent access and error during import.
Comment 1 Szymon Ptaszkiewicz CLA 2010-11-03 12:03:05 EDT 
Created attachment 182305 [details]
Patch v.0.1
Comment 2 Boris Bokowski CLA 2010-11-15 11:51:51 EST 
Does the thread that calls ContentTypeDecorator.decorate hold any other locks at the time it does beginRule?
Comment 3 Oleg Besedin CLA 2010-11-15 16:48:02 EST 
(In reply to comment #2)
> Does the thread that calls ContentTypeDecorator.decorate hold any other locks
> at the time it does beginRule?

It does not seem to hold any other locks, here is the typical state:

===

"Worker-8" prio=6 tid=0x1ffd4400 nid=0x13ac in Object.wait() [0x223ef000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x0b1c13e0> (a java.lang.Object)
	at org.eclipse.core.internal.jobs.ThreadJob.waitForRun(ThreadJob.java:272)
	- locked <0x0b1c13e0> (a java.lang.Object)
	at org.eclipse.core.internal.jobs.ThreadJob.joinRun(ThreadJob.java:199)
	at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:92)
	at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:286)
	at org.eclipse.ui.internal.ide.ContentTypeDecorator.decorate(ContentTypeDecorator.java:46)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:269)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:81)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:365)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:347)
	at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:371)
	at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:331)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

   Locked ownable synchronizers:
	- None


===

(The lock on the bottom is from Job.getJobManager().beginRule().)
Comment 4 Boris Bokowski CLA 2010-11-15 17:04:55 EST 
Thanks Oleg. +1 for 3.6.2.
Comment 5 Oleg Besedin CLA 2010-11-16 11:32:05 EST 
Patch applied to R3_6_maintenance. I also incremented version of the "org.eclipse.ui.ide" bundle from 3.6.1 to 3.6.2.
Comment 6 Oleg Besedin CLA 2011-01-20 11:02:50 EST 
Verified that the code is present in M20110119-0834.