Bugzilla – Full Text Bug Listing
| Summary: | [Legacy] Failing event PREPARE in state CLEAN : state machine issue with legacy mode | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Alex Lagarde <alex.lagarde> | ||||||||||||||||||
| Component: | cdo.legacy | Assignee: | Martin Fluegge <martin.fluegge> | ||||||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | Eike Stepper <stepper> | ||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||
| Priority: | P3 | CC: | alex.lagarde, mariot.chauvin, steve.monnier | ||||||||||||||||||
| Version: | 4.1 | Flags: | martin.fluegge:
review?
(stepper) |
||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||||
| OS: | Windows 7 | ||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||
| Bug Depends on: | |||||||||||||||||||||
| Bug Blocks: | 359966, 364536 | ||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
|
Description
Alex Lagarde
Alex, your stack trace does not match the code from HEAD. I assume that you are not using CDO from the repository. Which version are you using? CDO 3.x or 4.0? Hi Martin, I'm using the CDO 4.0 release version (v20110608). Martin, any news about this bug ? Created attachment 203415 [details] Transition workaround I attached a small patch containing the workaround on CDOStateMachine transitions described by Alex in http://www.eclipse.org/forums/index.php/t/220818/ sorry for the late response. I must have overseen this one. Steve, thnaks for the patch. I am usually not a fan of changing CDOs internals if legacy is involved. I would like to find a solution for this in legacy without changing the core. Since you could provide a patch, could one of you provide a small test which reproduces the problem. This you help me a lot. Thanks :) Hi Martin, I will provide a test to reproduce this problem as soon as possible. (In reply to comment #5) > sorry for the late response. I must have overseen this one. Steve, thnaks for > the patch. I am usually not a fan of changing CDOs internals if legacy is > involved. I would like to find a solution for this in legacy without changing > the core. Since you could provide a patch, could one of you provide a small > test which reproduces the problem. This you help me a lot. Thanks :) > I will provide a test to reproduce this problem as soon as possible.
>
That's great. Thanks a lot. :)
Created attachment 203586 [details]
Transition workaround and test
Same patch with test cases in addition
Created attachment 203617 [details]
Test v1
Unfortunatelly the attached patch only demonstrates that the CDOStaeMachine Works correctly. Attaching or preparing an already clean object must lead to an error. That's why the test also fails in native.
I tried to write a test besing on the description given in the forum post, but did not succeed yet. Maybe one of you could use this as base and try to reproduce this with our test models?
I also could need some additional information:
- Is the containment relationship a single, or mutli value reference?
- What does "several instances" mean? 10, 100, more?
- Has User2 already openend a session and transaction, or does the error occur when loading the resource? Or both?
I am going back now to the code and continue trying to reproduce the errror.
Created attachment 203829 [details]
Metamodel to reproduce the issue
Created attachment 203831 [details] model to import on cdo repository Hi Martin, I finally managed to create a small metamodel to reproduce the issue. Steps to follow : - First user : Import the model on CDO repository - Second user : connect to this repository and open an editor on this shared resource - First user : Explore model to the "A" element (containing "D" and "B") - First user : Copy this "A" element on the same "E" container and commit - Second user : Receive multiple java.lang.IllegalStateException java.lang.IllegalStateException: Failing event PREPARE in state CLEAN for CDOLegacyWrapper[CImpl@OID18] (data=Pair[Transaction 1 [MAIN], []]) at org.eclipse.net4j.util.fsm.FiniteStateMachine.process(FiniteStateMachine.java:153) at org.eclipse.emf.internal.cdo.view.CDOStateMachine.prepare(CDOStateMachine.java:227) at org.eclipse.emf.internal.cdo.view.CDOStateMachine.attach(CDOStateMachine.java:191) at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.attached(CDOResourceImpl.java:1228) at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.attached(CDOResourceImpl.java:1219) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eBasicSetContainer(BasicEObjectImpl.java:1342) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseAdd(BasicEObjectImpl.java:1423) at bug352204.impl.BImpl.setOwnedC(BImpl.java:100) at bug352204.impl.BImpl.eSet(BImpl.java:145) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:1081) at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.revisionToInstanceFeature(CDOLegacyWrapper.java:544) at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.revisionToInstance(CDOLegacyWrapper.java:391) at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.cdoInternalPostLoad(CDOLegacyWrapper.java:278) In the stack trace, it presents that the issue comes from "setOwnedC" relation on "B". However, you will not have the exceptions if you remove the relation of the last GMF Node element to "C". Hi Martin, I forgot to add in my previous comment, that I reproduce this issue on branch 4.0 Maintenance. Did you manage to reproduce it as well? Thanks, Steve (In reply to comment #12) > Hi Martin, > > I forgot to add in my previous comment, that I reproduce this issue on branch > 4.0 Maintenance. Did you manage to reproduce it as well? > Does this mean that you only tested on 4.0 or that you were not able to reproduce it on the CDO 4.1 stream? I'll try to set up your environment this evening. (In reply to comment #13) > (In reply to comment #12) > > Hi Martin, > > > > I forgot to add in my previous comment, that I reproduce this issue on branch > > 4.0 Maintenance. Did you manage to reproduce it as well? > > > > Does this mean that you only tested on 4.0 or that you were not able to > reproduce it on the CDO 4.1 stream? > > I'll try to set up your environment this evening. Indeed, I only tried on 4.0. Thanks Hi Steve, I successfully imported the models, but somehow did not find a test class. The test_bug352205 project only contains a resource file. Where can I find the specific java file? Cheers, Martin Hi Martin, Actually, I thought it would be quicker to provide a test project and the previous scenario in order that you can reproduce the issue as soon as possible :). Regards Hi Steve, but the test project is missing some file to execute the scenario you described. Since you showed the exception I guess you already have some piece of code which leads to the exception. This would be helpful. If I would have something where I can debug through it would be easier to understand the problem and to provide a solution. I could write an own test based on your description, but if you already have one this would lead to unnecessary effort. I currently busy preparing the Eclipse Con so writing an own test would take some time ;) Ok I see the misunderstanding, I reproduced the scenario manually not programmatically. I'm not using any other file, I just opened a session with the cdo session view, created a new resource and imported the model that is in the test project and open a CDO Editor on this imported resource. Then a second user (another eclipse) opens a CDO Editor on this imported resource. Next one of these users Explore model to the "A" element (containing "D" and "B"), Copy this "A" element on the same "E" container and commit. As a result the other user Receive multiple java.lang.IllegalStateException. I'm looking into the cdo test framework to create a java test case. Created attachment 204294 [details]
JUnit test case of the scenario
Hi Martin,
I managed to write a test case (might be a bit tricky) that reproduces my previous scenario and fails with the same exception with CDO 4.0 maintenance branch.
Created attachment 204360 [details]
Test v2
That's really a strange bug and a complex scenario. Legacy, multiple session, differnt threads, importing resources and GMF. That's tough.
I simplified the test to exclude some potentiel problems. It occurs to me that the bug only occurs if the second user reads the first object from the resource.
Not sure why this can influence the second thread. Also the timing in the test seems to be related to the problem.
progress is ongoing...
You can also use the test case written for https://bugs.eclipse.org/bugs/show_bug.cgi?id=359966 to reproduce the issue. These are disabled until this bug is fixed (they demo the same effect): org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_359966_Test._testChangesImportWithNewLegacyElementsWithCustomFileAndReconstructSavePoints() org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_359966_Test._testChangesImportWithNewLegacyElementsWithCustomFileAndNotReconstructSavePoints() (In reply to comment #21) > You can also use the test case written for > https://bugs.eclipse.org/bugs/show_bug.cgi?id=359966 to reproduce the issue. See also diagram https://bugs.eclipse.org/bugs/attachment.cgi?id=207400 Start investigating Created attachment 207564 [details]
Test Case Overview
I managed to reduce the complexity of the test (see attached figure). Still this one was not that trivial to detect. The problem comes (again) from the recursive nature of legacy. In fact, when processing the object tree to fill the legacy objects the Diagram object in the tree is created and initialize as while processing the container of the NodeImpl (which is the starting point in the test). Doing this, the call of AbstractCDOView.cleanup() sets the Diagram into the CDOState CLEAN before calling cdoInternalPostLoad and continuing with the processing.
The problem occurs if the container of the Diagram (DImpl) is processed in the next step. While all references of DImpl are handled also the containment reference (data) to the DiagramImpl is set.
But containment references are currently only handled with a call to eSet(), which unfortunately invokes a reverses setting (eBasicSetContainer) for the parent (DImpl).
If now the object is attached to the resource it is already in state CLEAN, wich leads to the exception.
The problem comes from the call of eSet since there is no reflective way to call only one site of this operation (in this case basicSetData(EObject)).
I have different ideas how to face this problem. But I am optimistic that I can provide a patch soon.
Currently the best way is to avoid the multiple addition to the resource in case of Legacy. I provided the changes under bugs/352204. Changed slightly, merged to master, pushed to upstream: commit 97b7955f6e86c473559a920869603e6039994879 Author: Eike Stepper <stepper@esc-net.de> 2011-11-27 09:12:12 Committer: Eike Stepper <stepper@esc-net.de> 2011-11-27 09:12:12 Parent: 5e576c5f2975be19b3d81627aa163c7022b5329f ([352204] [Legacy] Failing event PREPARE in state CLEAN : state machine issue with legacy mode https://bugs.eclipse.org/bugs/show_bug.cgi?id=352204) Branches: origin/bugs/352204, origin/master, master, bugs/352204 [352204] [Legacy] Failing event PREPARE in state CLEAN : state machine issue with legacy mode https://bugs.eclipse.org/bugs/show_bug.cgi?id=352204 Port to 4.0 via bug 364904. Closing. |