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

Bug 172382

Summary: ServerCore static initializer causes deadlock
Product: [WebTools] WTP ServerTools Reporter: Elson Yuen <eyuen7>
Component: wst.serverAssignee: Tim deBoer <deboer>
Status: CLOSED FIXED QA Contact: Tim deBoer <deboer>
Severity: normal    
Priority: P3 CC: arvera, balakuma, david_williams
Version: 1.5   
Target Milestone: 1.5.3 M153   
Hardware: PC   
OS: Windows XP   
Whiteboard: PMC_approved
Attachments:
Description Flags
Patch to ServerCore none

Description Elson Yuen CLA 2007-01-31 15:49:41 EST
Build ID: WTP1.5.3

Steps To Reproduce:
In the ServerCore class in wst.server.core, the current code has a static initializer on the loading up the startup extension point org.eclipse.wst.server.core.internalStartup.  Given that ServerCore is a very common class to be used in a very large number of server tools operations, e.g. even for a simple operation like adding the runtime life cycle listener.

If there is any startup extension implementation happens to be using the ServerCore class, it will causes various deadlock issues.  

Given that the ServerCore class is involved in a large number of server tools operations, the startup extension point should not be initialized in the static initilizer of the ServerCore class.

More information:
Comment 1 Tim deBoer CLA 2007-01-31 16:03:19 EST
*** Bug 172379 has been marked as a duplicate of this bug. ***
Comment 2 Tim deBoer CLA 2007-01-31 18:33:58 EST
Created attachment 57955 [details]
Patch to ServerCore

The full explanation of this bug is somewhat complicated and I've discussed it with the originator off-line. The short explanation is:

 * This deadlock is timing related and only occurs in certain rare situations. The code has been in since WTP started, but for whatever reason (JDK, memory, timing, etc.) it is now hit consistently in the adopter testcase.
 * In case there is any question, this testcase has proved that plugins should never call methods in their startup() that may block. If the lock is held by another plugin (on another job or thread), this can cause deadlock due to other locks held by OSGi and the classloaders.
 * org.eclipse.jst.server.core's JavaServerPlugin is calling ServerCore.addRuntimeListener() during startup, a method which should not be blocking, but currently is.
 * ServerCore has a static initializer to ensure that the API methods like getServer() are initialized before users call them. However, the static initializer causes all methods on the class to block due to the classloader's lock.
 * The attached patch removes the static initializer and moves initialization into a method. This initialization is called (and still blocks) from regular API calls like getServer(), but allows calls that don't require initialization (like addRuntimeListener()) to proceed. This both avoids the classloader lock and stops other methods from blocking unnecessarily.
 * Similar code was released to WTP 2.0 M4 and has been running without problems. The adopter has tested this patch.
Comment 3 Tim deBoer CLA 2007-01-31 18:35:29 EST
Raising for PMC approval. I will abstain on Arthur's PMC vote :) unless he wishes to vote himself.
Comment 4 David Williams CLA 2007-02-01 02:22:39 EST
+1 looks important, well reasoned, and well tested. 
Thanks. 
Comment 5 Arthur Ryman CLA 2007-02-02 11:19:02 EST
+1 for WTP 1.5.3. Patch looks ok.
Comment 6 Tim deBoer CLA 2007-02-02 11:32:13 EST
Fix released to 1.5.3 builds.
Comment 7 John Lanuti CLA 2007-04-03 11:32:43 EDT
Closing as fixed since WTP 1.5.3.  Please reopen if closed in error.