Community
Participate
Working Groups
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)
Created attachment 173873 [details] patch
Created attachment 173876 [details] patch
* 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.
We have had numerous issues in this area and would like to review this change.
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!)
Please go ahead with the change. We will re-visit this for 3.2.2.
Released changes to Maintenance and HEAD. Thanks.
