Bug 513407 - Xtext Transaction error during resource loading and reloading
Summary: Xtext Transaction error during resource loading and reloading
Status: CLOSED FIXED
Alias: None
Product: Sirius
Classification: Modeling
Component: Core (show other bugs)
Version: 4.0.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 6.0.0   Edit
Assignee: Project inbox CLA
QA Contact: Florian Barbin CLA
URL:
Whiteboard: backport, needtest
Keywords: triaged
: 526513 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-03-09 14:30 EST by Zoltan Ujhelyi CLA
Modified: 2018-06-27 11:55 EDT (History)
7 users (show)

See Also:

Attachments
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 Zoltan Ujhelyi CLA 2017-03-09 14:30:42 EST 
This issue is opened as a follow-up for the forum thread https://www.eclipse.org/forums/index.php?t=rview&goto=1755948

In case of a textual language using Xbase (the expression language of Xtext), during the loading and reloading of resources we have noticed Transaction Errors, like as follows:

!ENTRY org.apache.log4j 4 0 2016-10-06 11:42:08.434
!MESSAGE org.eclipse.xtext.xbase.resource.BatchLinkableResource - resolution of uriFragment '|4' failed.

!STACK 0
java.lang.IllegalStateException: Cannot modify resource set without a write transaction
at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.assertWriting(TransactionChangeRecorder.java:348)
at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.appendNotification(TransactionChangeRecorder.java:302)
at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.processObjectNotification(TransactionChangeRecorder.java:284)
at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.notifyChanged(TransactionChangeRecorder.java:240)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374)
at org.eclipse.emf.common.notify.impl.NotificationImpl.dispatch(NotificationImpl.java:1027)
at org.eclipse.xtext.common.types.impl.JvmSpecializedTypeReferenceImpl.setEquivalent(JvmSpecializedTypeReferenceImpl.java:110)
at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver._doPrepare(LogicalContainerAwareReentrantTypeResolver.java:627)
at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.doPrepare(LogicalContainerAwareReentrantTypeResolver.java:465)
at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.prepareMembers(LogicalContainerAwareReentrantTypeResolver.java:500)
at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver._doPrepare(LogicalContainerAwareReentrantTypeResolver.java:471)
at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.doPrepare(LogicalContainerAwareReentrantTypeResolver.java:459)
at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.prepare(LogicalContainerAwareReentrantTypeResolver.java:409)
at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.computeTypes(LogicalContainerAwareReentrantTypeResolver.java:696)
at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.resolve(DefaultReentrantTypeResolver.java:163)
at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.reentrantResolve(DefaultReentrantTypeResolver.java:139)
at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$LazyResolvedTypes.resolveTypes(CachingBatchTypeResolver.java:80)
at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:57)
at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:1)
at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:37)
at org.eclipse.xtext.util.OnChangeEvictingCache.execWithoutCacheClear(OnChangeEvictingCache.java:129)
at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver.doResolveTypes(CachingBatchTypeResolver.java:53)
at org.eclipse.xtext.xbase.typesystem.internal.AbstractBatchTypeResolver.resolveTypes(AbstractBatchTypeResolver.java:69)
at org.eclipse.xtext.xbase.resource.BatchLinkingService.resolveBatched(BatchLinkingService.java:60)
at org.eclipse.xtext.xbase.resource.BatchLinkingService.resolveBatched(BatchLinkingService.java:41)
at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getEObject(BatchLinkableResource.java:117)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:223)
at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:203)
at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:259)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1477)
at org.eclipse.xtext.xbase.impl.XAbstractFeatureCallImplCustom.getFeature(XAbstractFeatureCallImplCustom.java:48)
at org.eclipse.xtext.xbase.impl.XAbstractFeatureCallImpl.eGet(XAbstractFeatureCallImpl.java:490)
at org.eclipse.xtext.xbase.impl.XFeatureCallImpl.eGet(XFeatureCallImpl.java:256)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1011)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1003)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:998)
at org.eclipse.sirius.ecore.extender.tool.internal.ReferencesResolver.resolveCrossReferences(ReferencesResolver.java:100)
at org.eclipse.sirius.ecore.extender.tool.internal.ReferencesResolver.doResolveAll(ReferencesResolver.java:93)
at org.eclipse.sirius.ecore.extender.tool.internal.ReferencesResolver.resolve(ReferencesResolver.java:74)
at org.eclipse.sirius.ecore.extender.tool.api.ModelUtils.resolveAll(ModelUtils.java:453)
at org.eclipse.sirius.business.internal.session.danalysis.SessionResourcesTracker.forceLoadingOfEveryLinkedResource(SessionResourcesTracker.java:173)
at org.eclipse.sirius.business.internal.session.danalysis.SessionResourcesTracker.initialize(SessionResourcesTracker.java:95)
at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.open(DAnalysisSessionImpl.java:1161)
at org.eclipse.sirius.business.internal.session.SessionManagerImpl.openSession(SessionManagerImpl.java:390)
at org.eclipse.sirius.ui.tools.internal.views.common.modelingproject.OpenRepresentationsFileJob.performOpenSession(OpenRepresentationsFileJob.java:157)
at org.eclipse.sirius.ui.tools.internal.views.common.modelingproject.OpenRepresentationsFileJob.runInWorkspace(OpenRepresentationsFileJob.java:126)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55


I could reproduce this issue deterministically with the domain model example provided by Xtext with a very trivial Sirius viewpoint defined (see https://github.com/ujhelyiz/xbase-sirius-example for source code).

To reproduce this trace, open the domain.test project in Project explorer or Model explorer to initialize a Sirius session (there is no need to open any editor at all), and the exception was thrown when the editors defined by the other projects were installed.

During debugging, I have found two places were such exceptions were thrown by Sirius

* In DAnalysisSessionImpl when initializing the SessionResourcesTracker, the resolution call is called without any transactions. This caused linking errors when initializing the Sirius Session, see the original exception trace.
* In SessionResourcesSynchronizer, when the model was changed outside a Sirius editor (e.g. updated in the original Xtext editor), the reload was included in an exclusive, read-only transaction. However, in this case very similar exceptions were thrown to the original post.

I will also provide a Gerrit change shortly with a simple fix of moving this actions inside a write transaction.
Comment 1 Eclipse Genie CLA 2017-03-09 14:32:06 EST 
New Gerrit change created: https://git.eclipse.org/r/92724
Comment 2 Pierre-Charles David CLA 2017-03-10 03:26:31 EST 
Hi Zoltan, and thanks for the patch.

W'ere busy getting M6 ready (it's next week), so I'm not sure we'll be able to review this right now, but I'm putting this in the scope for M7, at least to avoid dropping the ball again.

It seems that the current version of the patch has caused a deadlock in one of our tests, see https://hudson.eclipse.org/sirius/job/sirius.gerrit.tests-neon/1697/PLATFORM=neon,SUITE=gerrit-junit,jdk=JDK-1.8.0/console. It's in the org.eclipse.sirius.tests.unit.api.semantic.XSDSemanticResourceTests.testAirResourceAddition() test. It might be the patch, or the test itself.
Comment 3 Pierre-Charles David CLA 2017-05-18 05:57:17 EDT 
Moving to 5.1, sorry. I hoped I would find the time to review the impacts of the proposed patch, but we're past M7 so this will have to wait.
Comment 4 Eirik Grønsund CLA 2017-05-18 09:43:38 EDT 
(In reply to Pierre-Charles David from comment #2)
> Hi Zoltan, and thanks for the patch.
> 
> W'ere busy getting M6 ready (it's next week), so I'm not sure we'll be able
> to review this right now, but I'm putting this in the scope for M7, at least
> to avoid dropping the ball again.
> 
> It seems that the current version of the patch has caused a deadlock in one
> of our tests, see
> https://hudson.eclipse.org/sirius/job/sirius.gerrit.tests-neon/1697/
> PLATFORM=neon,SUITE=gerrit-junit,jdk=JDK-1.8.0/console. It's in the
> org.eclipse.sirius.tests.unit.api.semantic.XSDSemanticResourceTests.
> testAirResourceAddition() test. It might be the patch, or the test itself.

Running the "All Sirius Tests" I was not able to produce a deadlock or any side effects from the patch. As far as I can see, the  testAirResourceAddition() does not visit the the methods where the patch is applied, but the addASuperTypeToSemanticElementInAnotherResourceSet() in the DAnalysisModelUpdateTests class in the same test package does.

It seems like the link in our reply is broken. Maybe my testing was not extensive enough. I used JDk 1.8 running the tests.
Comment 5 Eirik Grønsund CLA 2017-05-18 09:59:36 EDT 
(In reply to Eirik  Grønsund from comment #4)
> (In reply to Pierre-Charles David from comment #2)
> > Hi Zoltan, and thanks for the patch.
> > 
> > W'ere busy getting M6 ready (it's next week), so I'm not sure we'll be able
> > to review this right now, but I'm putting this in the scope for M7, at least
> > to avoid dropping the ball again.
> > 
> > It seems that the current version of the patch has caused a deadlock in one
> > of our tests, see
> > https://hudson.eclipse.org/sirius/job/sirius.gerrit.tests-neon/1697/
> > PLATFORM=neon,SUITE=gerrit-junit,jdk=JDK-1.8.0/console. It's in the
> > org.eclipse.sirius.tests.unit.api.semantic.XSDSemanticResourceTests.
> > testAirResourceAddition() test. It might be the patch, or the test itself.
> 
> Running the "All Sirius Tests" I was not able to produce a deadlock or any
> side effects from the patch. As far as I can see, the 
> testAirResourceAddition() does not visit the the methods where the patch is
> applied, but the addASuperTypeToSemanticElementInAnotherResourceSet() in the
> DAnalysisModelUpdateTests class in the same test package does.
> 
> It seems like the link in our reply is broken. Maybe my testing was not
> extensive enough. I used JDk 1.8 running the tests.

Sorry, forgot to mention that I used the defaults from the "Oomph Environment Configuration Guide" at the "Sirius/Contributing" site when running the tests on the Neon target only.
Comment 6 Pierre-Charles David CLA 2017-09-05 05:45:09 EDT 
So it seems in its current form the patch causes some regressions in our test suites. It's not XSDSemanticResourceTests which causes problems as I had though, it's in SiriusControlAndCrossReferenceInMultiSessionTest.testControlImpactOnSemanticResource().

My current understanding is that the change in SessionResourcesSynchronizer to use TED.execute(RecordingCommand) instead of TED.runExclusive(RunnableWithResult) changes the type and/or timing of notifications we receive about workspace changes. This causes the ResourceSetSync, which keeps track of our vision of the resources' state, to see a particular resource as CONFLICTING_DELETED (modified in memory, removed on disk) whereas without the patch it sees it as DELETED (removed on disk, but the in-memory version was clean). The CONFLICTING_DELETED triggers the opening of a message dialog to ask the user what to do:

 at org.eclipse.jface.dialogs.MessageDialog.openQuestion(MessageDialog.java:518)
 at org.eclipse.sirius.ui.tools.api.command.AbstractSWTCallback.openQuestion(AbstractSWTCallback.java:270)
 at org.eclipse.sirius.ui.tools.api.command.AbstractSWTCallback.shouldRemove(AbstractSWTCallback.java:237)
 at org.eclipse.sirius.business.internal.session.ReloadingPolicyImpl.shouldRemove(ReloadingPolicyImpl.java:138)
 at org.eclipse.sirius.business.internal.session.ReloadingPolicyImpl.handleExternalDeleteConflict(ReloadingPolicyImpl.java:99)
 at org.eclipse.sirius.business.internal.session.ReloadingPolicyImpl.getActions(ReloadingPolicyImpl.java:73)
 at org.eclipse.sirius.business.internal.session.danalysis.SessionResourcesSynchronizer.statusesChanged(SessionResourcesSynchronizer.java:112)
 at org.eclipse.sirius.common.tools.api.resource.ResourceSetSync.notifyClientsInBatch(ResourceSetSync.java:392)
 at org.eclipse.sirius.common.tools.api.resource.ResourceSetSync.statusesChanged(ResourceSetSync.java:447)
 at org.eclipse.sirius.common.tools.internal.resource.ResourceSyncClientNotifier.run(ResourceSyncClientNotifier.java:77)
 at org.eclipse.sirius.common.tools.internal.resource.EditingSessionWorkspaceListener.resourceChanged(EditingSessionWorkspaceListener.java:59)

The test does not expect the dialog to open, so it stays there waiting forever. Not technically a deadlock, but the result is the same.

I don't understand yet exactly how/why the notifications we receive are different, and strangely even with the patch I can not reproduce the problem when launching the SiriusControlAndCrossReferenceInMultiSessionTest alone (outside of the full test suite).

As much as I would have liked to include this in 5.1, it seems to cause subtle changes rather deep in the session management code, so unless I find a way to fix that I can convince myself is safe, it may have to slip again to 6.0. Sorry about that!
Comment 7 Nicolas Rouquette CLA 2017-09-20 13:54:27 EDT 
It seems that we're experiencing this problem as well with Sirius 4.1.6 on Neon.

> * In DAnalysisSessionImpl when initializing the SessionResourcesTracker, 
> the resolution call is called without any transactions. 
> This caused linking errors when initializing the Sirius Session, 
> see the original exception trace.

In our case (see https://github.com/JPL-IMCE/gov.nasa.jpl.imce.oml/issues/114), 
the stack trace is a bit different but the problem is fundamentally the same.

1) After launching Eclipse (in our case, a runtime Eclipse based on our Sirius-based product configuration), the runtime eclipse shows the "Resource" perspective.

2) Suppose the workspace already contains a project previously "Convert to Modeling Project" (i.e., it has a "representations.aird" file)

3) As soon as one attempts to open such a project, the Eclipse builder kicks off and what happens depends on the contents of this "representations.aird" file.

- If there is no Sirius viewpoint/diagram, then we're OK.

- If there is a Sirius viewpoint/diagram, then we get a similar behavior:

        Caused by: java.lang.IllegalStateException: Cannot modify resource set without a write transaction
        at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.assertWriting(TransactionChangeRecorder.java:349)
	...
        at org.eclipse.emf.transaction.util.TransactionUtil.runExclusive(TransactionUtil.java:328)
	at org.eclipse.sirius.business.internal.session.danalysis.SessionResourcesTracker.getSemanticResources(SessionResourcesTracker.java:149)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.getSemanticResources(DAnalysisSessionImpl.java:664)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.disableAndRemoveECrossReferenceAdapters(DAnalysisSessionImpl.java:311)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.close(DAnalysisSessionImpl.java:1250)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.open(DAnalysisSessionImpl.java:1201)
	at org.eclipse.sirius.business.internal.session.SessionManagerImpl.openSession(SessionManagerImpl.java:390)
	at org.eclipse.sirius.ui.tools.internal.views.common.modelingproject.OpenRepresentationsFileJob.performOpenSession(OpenRepresentationsFileJob.java:157)
	at org.eclipse.sirius.ui.tools.internal.views.common.modelingproject.OpenRepresentationsFileJob.runInWorkspace(OpenRepresentationsFileJob.java:126)
	... 2 more
Comment 8 Nicolas Rouquette CLA 2017-09-20 14:21:50 EDT 
At least in our case, the culprit was having *.xsd files in an Xtext/Modeling project.
Somehow, this causes the particular stack trace we got w/ Sirius 4.1.6 on Neon:

java.lang.RuntimeException: The modeling project "gov.nasa.jpl.imce.ontologies.public" is invalid: Problem during loading models: Cannot modify resource set without a write transaction
	at org.eclipse.sirius.ui.tools.internal.views.common.modelingproject.OpenRepresentationsFileJob.runInWorkspace(OpenRepresentationsFileJob.java:136)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: java.lang.IllegalStateException: Cannot modify resource set without a write transaction
	at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.assertWriting(TransactionChangeRecorder.java:349)
	at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.appendNotification(TransactionChangeRecorder.java:303)
	at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.processObjectNotification(TransactionChangeRecorder.java:285)
	at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.notifyChanged(TransactionChangeRecorder.java:241)
	at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374)
	at org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDConcreteComponentImpl.java:1153)
	at org.eclipse.emf.ecore.util.EcoreEList.dispatchNotification(EcoreEList.java:249)
	at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:304)
	at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:303)
	at org.eclipse.xsd.impl.XSDSchemaImpl.imported(XSDSchemaImpl.java:3120)
	at org.eclipse.xsd.impl.XSDImportImpl.handleResolvedSchema(XSDImportImpl.java:430)
	at org.eclipse.xsd.impl.XSDSchemaDirectiveImpl.resolve(XSDSchemaDirectiveImpl.java:393)
	at org.eclipse.xsd.impl.XSDImportImpl.importSchema(XSDImportImpl.java:416)
	at org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaImpl.java:2247)
	at org.eclipse.xsd.impl.XSDSchemaImpl.resolveNamedComponent(XSDSchemaImpl.java:2280)
	at org.eclipse.xsd.impl.XSDSchemaImpl.resolveAttributeDeclaration(XSDSchemaImpl.java:2302)
	at org.eclipse.xsd.impl.XSDConcreteComponentImpl.resolveAttributeDeclaration(XSDConcreteComponentImpl.java:2438)
	at org.eclipse.xsd.impl.XSDAttributeDeclarationImpl.patch(XSDAttributeDeclarationImpl.java:196)
	at org.eclipse.xsd.impl.XSDConcreteComponentImpl.patch(XSDConcreteComponentImpl.java:529)
	at org.eclipse.xsd.impl.XSDAttributeUseImpl.patch(XSDAttributeUseImpl.java:761)
	at org.eclipse.xsd.impl.XSDConcreteComponentImpl.patch(XSDConcreteComponentImpl.java:529)
	at org.eclipse.xsd.impl.XSDNamedComponentImpl.patch(XSDNamedComponentImpl.java:779)
	at org.eclipse.xsd.impl.XSDTypeDefinitionImpl.patch(XSDTypeDefinitionImpl.java:241)
	at org.eclipse.xsd.impl.XSDComplexTypeDefinitionImpl.patch(XSDComplexTypeDefinitionImpl.java:1049)
	at org.eclipse.xsd.impl.XSDConcreteComponentImpl.patch(XSDConcreteComponentImpl.java:529)
	at org.eclipse.xsd.impl.XSDNamedComponentImpl.patch(XSDNamedComponentImpl.java:779)
	at org.eclipse.xsd.impl.XSDElementDeclarationImpl.patch(XSDElementDeclarationImpl.java:542)
	at org.eclipse.xsd.impl.XSDConcreteComponentImpl.patch(XSDConcreteComponentImpl.java:529)
	at org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java:1596)
	at org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchemaImpl.java:2457)
	at org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDConcreteComponentImpl.java:1148)
	at org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSchemaImpl.java:887)
	at org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl.java:757)
	at org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl.java:790)
	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1518)
	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1297)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:259)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$ResourceLocator.demandLoadHelper(ResourceSetImpl.java:804)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$MappedResourceLocator.getResource(ResourceSetImpl.java:1204)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:352)
	at org.eclipse.sirius.ecore.extender.tool.api.ModelUtils.getResource(ModelUtils.java:312)
	at org.eclipse.sirius.business.internal.session.danalysis.SemanticResourceGetter.collectTopLevelSemanticResources(SemanticResourceGetter.java:50)
	at org.eclipse.sirius.business.internal.session.danalysis.SessionResourcesTracker$1.run(SessionResourcesTracker.java:145)
	at org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl.runExclusive(TransactionalEditingDomainImpl.java:328)
	at org.eclipse.emf.transaction.util.TransactionUtil.runExclusive(TransactionUtil.java:328)
	at org.eclipse.sirius.business.internal.session.danalysis.SessionResourcesTracker.getSemanticResources(SessionResourcesTracker.java:149)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.getSemanticResources(DAnalysisSessionImpl.java:664)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.disableAndRemoveECrossReferenceAdapters(DAnalysisSessionImpl.java:311)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.close(DAnalysisSessionImpl.java:1250)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.open(DAnalysisSessionImpl.java:1201)
	at org.eclipse.sirius.business.internal.session.SessionManagerImpl.openSession(SessionManagerImpl.java:390)
	at org.eclipse.sirius.ui.tools.internal.views.common.modelingproject.OpenRepresentationsFileJob.performOpenSession(OpenRepresentationsFileJob.java:157)
	at org.eclipse.sirius.ui.tools.internal.views.common.modelingproject.OpenRepresentationsFileJob.runInWorkspace(OpenRepresentationsFileJob.java:126)
	... 2 more

Removing these *.xsd files and relaunching with "-clean" fixed this.

It seems that there may be a disconnect between what Sirius' ModelUtils.getResource() expects w.r.t. whether this is done with or without transaction support and what happens as a consequence of EMF notifications that may or may not require transaction support.

This is an educated guess.
Comment 9 Pierre-Charles David CLA 2017-09-21 02:35:08 EDT 
Thanks for the additional information. Improving Xtext compatibility and workspace synchronization issues in general are part of the themes we'd like to address for 6.0, but this will probably require deep (and careful) changes to get right, so I'm not sure how much it will be possible to backport in 5.1.x. I'm adding the "backport" keyword to keep an eye on this, and if some of the changes we make can be safely backported we'll try to do that.
Comment 10 Pierre-Charles David CLA 2017-12-06 10:17:56 EST 
*** Bug 526513 has been marked as a duplicate of this bug. ***
Comment 11 Laurent Fasani CLA 2018-02-19 09:43:27 EST 
I am tempted to confirm the analysis in comment 6.

>My current understanding is that the change in SessionResourcesSynchronizer to use TED.execute(RecordingCommand) instead of TED.runExclusive(RunnableWithResult) changes the type and/or timing of notifications we receive about workspace changes. This causes the ResourceSetSync, which keeps track of our vision of the resources' state, to see a particular resource as CONFLICTING_DELETED (modified in memory, removed on disk) whereas without the patch it sees it as DELETED (removed on disk, but the in-memory version was clean). The CONFLICTING_DELETED triggers the opening of a message dialog to ask the user what to do:

The resource is seen as CONFLICTING_DELETED because the resource was DIRTY before we receive the workspace eclipse notification of RESOURCE_DELETED. I think it is due because of save failing in step before.
I thought, at the beginning, that SiriusCrossReferenceAdapterTests (that is run just before XSDSemanticResourceTests) was the cause of XSDSemanticResourceTests failure. However, launching the test locally, I noticed that the test randomly has a "save fail call stack" 
CALL STACK 1: (got with ot without the patchset)
java.lang.NullPointerException
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.doSave(DAnalysisSessionImpl.java:845)
	at org.eclipse.sirius.business.internal.session.danalysis.Saver.wrappedSave(Saver.java:142)
	at org.eclipse.sirius.business.internal.session.danalysis.Saver.access$0(Saver.java:131)
	at org.eclipse.sirius.business.internal.session.danalysis.Saver$1.run(Saver.java:119)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2262)
	at org.eclipse.sirius.business.internal.session.danalysis.Saver.saveNow(Saver.java:116)
	at org.eclipse.sirius.business.internal.session.danalysis.Saver.save(Saver.java:93)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.save(DAnalysisSessionImpl.java:802)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.save(DAnalysisSessionImpl.java:797)
	at org.eclipse.sirius.business.internal.session.danalysis.SaveSessionJob.run(SaveSessionJob.java:67)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Typically, that can occur if session has been closed before the SaveSessionJob is executed.

CALL STACK 2: (only with the the patchset)
java.util.ConcurrentModificationException
	at org.eclipse.emf.common.util.ArrayDelegatingEList$EIterator.checkModCount(ArrayDelegatingEList.java:887)
	at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:706)
	at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:692)
	at org.eclipse.sirius.tests.sample.component.util.PayloadMarkerAdapter.getPayloadMarker(PayloadMarkerAdapter.java:82)
	at org.eclipse.sirius.tests.sample.component.util.PayloadMarkerAdapter.isPayload(PayloadMarkerAdapter.java:78)
	at org.eclipse.sirius.tests.sample.component.impl.ComponentImpl.getChildren(ComponentImpl.java:256)
	at org.eclipse.sirius.tests.sample.component.impl.ComponentImpl.eGet(ComponentImpl.java:420)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1011)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1003)
	at org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImpl.hasNext(EContentsEList.java:439)
	at org.eclipse.emf.ecore.util.EcoreUtil$ProperContentIterator.hasNext(EcoreUtil.java:1356)
	at org.eclipse.emf.common.util.AbstractTreeIterator.next(AbstractTreeIterator.java:139)
	at com.google.common.collect.Iterators.indexOf(Iterators.java:728)
	at com.google.common.collect.Iterators.any(Iterators.java:641)
	at org.eclipse.sirius.business.internal.session.IsModifiedSavingPolicy$ResourceHasReferenceTo.apply(IsModifiedSavingPolicy.java:228)
	at org.eclipse.sirius.business.internal.session.IsModifiedSavingPolicy$ResourceHasReferenceTo.apply(IsModifiedSavingPolicy.java:1)
	at com.google.common.collect.Iterators$6.computeNext(Iterators.java:617)
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:145)
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:140)
	at com.google.common.collect.Iterators.addAll(Iterators.java:366)
	at com.google.common.collect.Iterables.addAll(Iterables.java:332)
	at org.eclipse.sirius.business.internal.session.IsModifiedSavingPolicy.computeResourcesToSave(IsModifiedSavingPolicy.java:164)
	at org.eclipse.sirius.business.api.session.AbstractSavingPolicy.save(AbstractSavingPolicy.java:57)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl$1.run(DAnalysisSessionImpl.java:829)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.doSave(DAnalysisSessionImpl.java:840)
	at org.eclipse.sirius.business.internal.session.danalysis.Saver.wrappedSave(Saver.java:142)
	at org.eclipse.sirius.business.internal.session.danalysis.Saver.access$0(Saver.java:131)
	at org.eclipse.sirius.business.internal.session.danalysis.Saver$1.run(Saver.java:119)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2262)
	at org.eclipse.sirius.business.internal.session.danalysis.Saver.saveNow(Saver.java:116)
	at org.eclipse.sirius.business.internal.session.danalysis.Saver.save(Saver.java:93)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.save(DAnalysisSessionImpl.java:802)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.save(DAnalysisSessionImpl.java:797)
	at org.eclipse.sirius.business.internal.session.danalysis.SaveSessionJob.run(SaveSessionJob.java:67)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Note that I am not able to reproduce the test KO in my development environment even launching the suite itself.
So at this point of the analysis, I have only guesses, and among my guesses I would seek in making the WorkSpaceModifyOperation (that should be the context of a save) working well with the SaveSessionJob(which it self instanciate a WorkSpaceModifyOperation at some conditions). I will add a new comment if this guess is relevant.
Comment 12 Laurent Fasani CLA 2018-02-20 05:01:42 EST 
*Explanation of the issue*

Using a write transaction (with ted.getCommandStack().execute(Command)) instead of readOnly transaction (with ted.runExclusive(Runnable)) leads to different behavior.
With write transaction, at the end of the commit, the execution goes to the ValidateEditSupport (validateEdit.finalizeForCommit())
Sirius provides ResourceModifiedFieldUpdater, its own ValidateEditSupport that set the resource as modified if something has been "changed".

*Fix*
The fix is to consider that the resource is NOT modified from the moment it is loading. Then the global reload process lead to a NOT modified resource and then there is not conflict if the resource is deleted subsequently.
Comment 14 Laurent Fasani CLA 2018-02-22 05:16:59 EST 
Hello Zoltan, Eirik and Nicolas

The patchset originally proposed by Zoltan (thank you for that) has been merged on Sirius 6.0.0 master.

It would be interesting if you could reproduce your own scenario/use case to check if everything goes well now.

We've put a stable Sirius 6.0.0 build available for you here : http://download.eclipse.org/sirius/updates/stable/6.0.0-S20180221-035015/oxygen/

I hope you will enjoy it!
Comment 15 Laurent Fasani CLA 2018-02-23 11:54:45 EST 
Tests to check Sirius and XTect integration will be handle with the bug 531613
Comment 16 Laurent Fasani CLA 2018-02-23 11:56:19 EST 
need homologation scenario if possible
Comment 17 Laurent Fasani CLA 2018-03-09 05:22:15 EST 
there is not evident homologation scenario so far
Comment 18 Laurent Redor CLA 2018-06-27 11:55:12 EDT 
Available in Sirius 6.0.0, see https://wiki.eclipse.org/Sirius/6.0.0 for details