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

Bug 319400

Summary: Deadlock in ModelManager due to unhandled exception
Product: [WebTools] WTP Source Editing Reporter: Nick Sandonato <nsand.dev>
Component: wst.sseAssignee: Nick Sandonato <nsand.dev>
Status: RESOLVED FIXED QA Contact: Nitin Dahyabhai <thatnitind>
Severity: major    
Priority: P3 CC: cameron.bateman, carlin.rogers, david_williams, raghunathan.srinivasan
Version: 3.2Flags: david_williams: pmc_approved+
nsand.dev: pmc_approved? (raghunathan.srinivasan)
nsand.dev: pmc_approved? (naci.dai)
deboer: pmc_approved+
nsand.dev: pmc_approved? (neil.hauge)
nsand.dev: pmc_approved? (kaloyan)
thatnitind: review+
Target Milestone: 3.2.1   
Hardware: PC   
OS: Windows XP   
Whiteboard: PMC_approved WI51940
Attachments:
Description Flags
patch
none
patch none

Description Nick Sandonato CLA 2010-07-09 10:42:40 EDT 
A deadlock can occur in the Model Manager due to an unhandled exception when attempting to load a model. Once the exception occurs, the model stays in a "loading" state even though it was loaded with errors. The result is blocking on the shared object indefinitely at any other point where the shared object may be requested.

Below is the example of the exception causing this:


!MESSAGE Could not create content describer for com.google.gwt.eclipse.core.uibinder.content.xml. Content type has been disabled.
!STACK 0
org.apache.xerces.parsers.ObjectFactory$ConfigurationError: Provider org.apache.xerces.parsers.XIncludeAwareParserConfiguration could not be instantiated: org.apache.xerces.impl.dv.DVFactoryException: DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
	at org.apache.xerces.parsers.ObjectFactory.newInstance(Unknown Source)
	at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
	at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
	at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
	at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
	at org.eclipse.core.internal.content.XMLRootHandler.createParser(Unknown Source)
	at org.eclipse.core.internal.content.XMLRootHandler.parseContents(Unknown Source)
	at org.eclipse.core.runtime.content.XMLRootElementContentDescriber2.fillContentProperties(Unknown Source)
	at org.eclipse.core.runtime.content.XMLRootElementContentDescriber.checkCriteria(Unknown Source)
	at org.eclipse.core.runtime.content.XMLRootElementContentDescriber.describe(Unknown Source)
	at org.eclipse.core.runtime.content.XMLRootElementContentDescriber.describe(Unknown Source)
	at com.google.gwt.eclipse.core.uibinder.UiBinderXmlContentDescriber.describe(Unknown Source)
	at org.eclipse.core.internal.content.ContentTypeCatalog.describe(Unknown Source)
	at org.eclipse.core.internal.content.ContentTypeCatalog.collectMatchingByContents(Unknown Source)
	at org.eclipse.core.internal.content.ContentTypeCatalog.internalFindContentTypesFor(Unknown Source)
	at org.eclipse.core.internal.content.ContentTypeCatalog.internalFindContentTypesFor(Unknown Source)
	at org.eclipse.core.internal.content.ContentTypeCatalog.getDescriptionFor(Unknown Source)
	at org.eclipse.core.internal.content.ContentTypeCatalog.getDescriptionFor(Unknown Source)
	at org.eclipse.core.internal.content.ContentTypeMatcher.getDescriptionFor(Unknown Source)
	at org.eclipse.core.internal.resources.ContentDescriptionManager.readDescription(Unknown Source)
	at org.eclipse.core.internal.resources.ContentDescriptionManager.getDescriptionFor(Unknown Source)
	at org.eclipse.core.internal.resources.File.internalGetCharset(Unknown Source)
	at org.eclipse.core.internal.resources.File.getCharset(Unknown Source)
	at org.eclipse.core.internal.resources.File.getCharset(Unknown Source)
	at org.eclipse.core.internal.filebuffers.ResourceTextFileBuffer.cacheEncodingState(Unknown Source)
	at org.eclipse.core.internal.filebuffers.ResourceTextFileBuffer.initializeFileBufferContent(Unknown Source)
	at org.eclipse.core.internal.filebuffers.ResourceFileBuffer.create(Unknown Source)
	at org.eclipse.core.internal.filebuffers.TextFileBufferManager.connect(Unknown Source)
	at org.eclipse.wst.sse.core.internal.FileBufferModelManager.getModel(Unknown Source)
	at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl._doCommonGetModel(Unknown Source)
	at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl._commonGetModel(Unknown Source)
	at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl._commonGetModel(Unknown Source)
	at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl.getModelForRead(Unknown Source)
Comment 1 Nick Sandonato CLA 2010-07-09 11:31:54 EDT 
Created attachment 173873 [details]
patch
Comment 2 Nick Sandonato CLA 2010-07-09 11:40:23 EDT 
Created attachment 173876 [details]
patch
Comment 3 Nick Sandonato CLA 2010-07-09 12:01:09 EDT 
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such.

Can cause deadlocks if the model ever fails to load due to an exception.

* Is there a work-around? If so, why do you believe the work-around is insufficient?

None.

* How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added?

The fix has been manually tested along with running existing unit tests.

* Give a brief technical overview. Who has reviewed this fix?

Because the exception was never handled, it let the model stay in a "loading" state. The next time the model was requested, it would block since someone else appears to be loading the model. This fix allows a finally block to perform cleanup on the model so that the model will finish its loading state and other threads will not block on it anymore.

What is the risk associated with this fix?

Minimal. It's just some extra guarding around an error case.
Comment 4 Raghunathan Srinivasan CLA 2010-07-09 13:59:54 EDT 
We have had numerous issues in this area and would like to review this change.
Comment 5 David Williams CLA 2010-07-12 17:04:29 EDT 
This looks like an appropriate fix to me, so marking as +1. 

I'm not sure ... Raghu, I assume your comment means you want to review it further before it goes into a build? (Not sure if it'll help your deadlock cases, per se, since you've not reported 'exceptions' happening ... but, would be interesting, important if it did!)
Comment 6 Raghunathan Srinivasan CLA 2010-07-12 18:59:19 EDT 
Please go ahead with the change. We will re-visit this for 3.2.2.
Comment 7 Nick Sandonato CLA 2010-07-13 10:48:16 EDT 
Released changes to Maintenance and HEAD. Thanks.