Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 454264

Summary: Preference access in file locking code
Product: [ECD] Orion Reporter: John Arthorne <john.arthorne>
Component: ServerAssignee: John Arthorne <john.arthorne>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: pwebster
Version: unspecified   
Target Milestone: 8.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
Stack trace none

Description John Arthorne CLA 2014-12-05 11:57:29 EST 
Our FileLocker class accesses a preference value in its constructor. Since accessing preferences can involve additional locking and overhead, we should avoid this. It is a configuration setting that never changes so it only needs to be read once.
Comment 1 John Arthorne CLA 2014-12-05 12:51:31 EST 
Created attachment 249204 [details]
Stack trace

This is a stack trace from an Orion-based product of a deadlock while accessing preferences.
Comment 2 John Arthorne CLA 2014-12-05 12:55:33 EST 
Just some notes, mostly to myself: The stack shows a JVM level deadlock between OSGi class loading and the instance lock on RootPreferences (due to synchronized getChild method). 

The preferences need to do class loading to instantiate custom preference scopes. At the same time the ResourcesPlugin is in the middle of startup, trying to access preferences.

Nothing in Orion will directly fix this, but the risk of contention is reduced by avoiding preference access within our metadata locking code.