Eclipse Community Forums: EMF » Exception during CDO commit

Home » Modeling » EMF » Exception during CDO commit

Exception during CDO commit [message #1406353]

Sat, 09 August 2014 16:18

Eclipse User

I have installed CDO in Eclipse Kepler.

Whenever I try to do a commit (save) the model, I get this exception(given below).

My CDO version is 4.2.1 and Net4j is also 4.2.1.

Please help Sad

[ERROR] Invalid URI "cdo:proxy": java.lang.IllegalStateException: Different object was registered for OID1
org.eclipse.emf.cdo.util.InvalidURIException: Invalid URI "cdo:proxy": java.lang.IllegalStateException: Different object was registered for OID1
at org.eclipse.emf.internal.cdo.view.AbstractCDOView.registerProxyResource(AbstractCDOView.java:1380)
at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.registerProxy(CDOResourceImpl.java:1177)
at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.load(CDOResourceImpl.java:1086)
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.getResource(ResourceSetImpl.java:406)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:220)
at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:198)
at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:258)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1473)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eContainer(BasicEObjectImpl.java:770)
at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.revisionToInstanceFeature(CDOLegacyWrapper.java:640)
at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.revisionToInstance(CDOLegacyWrapper.java:466)
at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.cdoInternalPostLoad(CDOLegacyWrapper.java:358)
at org.eclipse.emf.internal.cdo.view.AbstractCDOView.cleanObject(AbstractCDOView.java:1185)
at org.eclipse.emf.internal.cdo.view.AbstractCDOView.createObject(AbstractCDOView.java:1113)
at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:993)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getObject(CDOTransactionImpl.java:1154)
at org.eclipse.emf.internal.cdo.view.AbstractCDOView.convertIDToObject(AbstractCDOView.java:1327)
at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.convertIDToObject(CDOStoreImpl.java:691)
at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.convertToEMF(CDOStoreImpl.java:659)
at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.getValueFromRevision(CDOLegacyWrapper.java:723)
at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.revisionToInstanceFeature(CDOLegacyWrapper.java:577)
at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.revisionToInstance(CDOLegacyWrapper.java:466)
at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.cdoInternalPostInvalidate(CDOLegacyWrapper.java:369)
at org.eclipse.emf.internal.cdo.view.CDOStateMachine$InvalidateTransition.execute(CDOStateMachine.java:1035)
at org.eclipse.emf.internal.cdo.view.CDOStateMachine$InvalidateTransition.execute(CDOStateMachine.java:1)
at org.eclipse.net4j.util.fsm.FiniteStateMachine.process(FiniteStateMachine.java:173)
at org.eclipse.emf.internal.cdo.view.CDOStateMachine.invalidate(CDOStateMachine.java:412)
at org.eclipse.emf.internal.cdo.view.AbstractCDOView.invalidate(AbstractCDOView.java:1493)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.invalidate(CDOTransactionImpl.java:2420)
at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(CDOViewImpl.java:869)
at org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRunnable.run(CDOViewImpl.java:1683)
at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:26)
at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:1)
at org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWorker.java:78)
at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWorker.java:70)
at org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Worker.java:206)
Caused by: java.lang.IllegalStateException: Different object was registered for OID1
at org.eclipse.emf.internal.cdo.view.AbstractCDOView.registerObject(AbstractCDOView.java:1396)
at org.eclipse.emf.internal.cdo.view.AbstractCDOView.registerProxyResource(AbstractCDOView.java:1367)
... 37 more

[Updated on: Sat, 09 August 2014 16:18] by Moderator

Re: Exception during CDO commit [message #1420016 is a reply to message #1406353]

Tue, 09 September 2014 07:44

Eclipse User

Hi,

I am getting this when switching from one repo to an alternate one and trying to load that new repo, it is likely however that the repo I am trying to load is corrupted somehow. We are still struggling to find out why at this point. One thought is that as we develop the metamodels and persist in our product under debug and the session is killed for whatever reason this causes a problem on reloading the CDO repo. Normal practice is to use the "close" command in the OSGi console. CDO does recover from the "crashes" but maybe in doing so it leaves something out that causes our corruption.

I have a number of these repos on a google drive shared with Eike, but he has not had any time to look at them. If anyone else is interested then I can share with them, just need their email address to do it.

I'll keep you informed of progress.

[Updated on: Tue, 09 September 2014 07:45] by Moderator

Re: Exception during CDO commit [message #1420037 is a reply to message #1420016]

Tue, 09 September 2014 08:18

Eclipse User

Hi Guys,

Just a quick note on the "damage repair" mechanism of the CDO DBStore: If the underlying DB system is really
transactional (has ACID proerties) the no harm should happen to it in case of ungraceful shutdown. Only a small numbers
of internal counters are kept in memory by CDO to optimize their use in a running session. Only these counters could get
corrupt if you don't shut down properly. And in case the next time you start the CDO server it detects the crash and
queries the DB to reconstruct the correct counter values.

I hope this helps and

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Am 09.09.2014 um 13:44 schrieb David Wynter:
> Hi,
>
> I am getting this when switching from one repo to an alternate one and trying to load that new repo, it is likely
> however that the repo I am trying to load is corrupted somehow. We are still struggling to find out why at this point.
> One thought is that as we develop the metamodels and persist in our product under debug and the session is killed for
> whatever reason this causes a problem on reloading the CDO repo. Normal practice is to use the "close" command in the
> OSGi console. Not CDO does recover from the "crashes" but maybe in doing so it leaves something out that causes our
> corruption.
>
> I have a number of these repos on a google drive shared with Eike, but he has not had any time to look at them. If
> anyone else is interested then I can share with them, just need their email address to do it.
>
> I'll keep you informed of progress.
>
>

Re: Exception during CDO commit [message #1421542 is a reply to message #1420037]

Thu, 11 September 2014 10:03

Eclipse User

Hi,

Thanks for eliminating that as a cause, it will save us time.

I am also getting this when opening a 900MB CDO H2 repo using the CDO Explorer view that comes with the CDO plugin install, as a Audit View and trying to export the View to a Resource. This is a massive amount of work we will lose if we cannot export this snapshot.

org.eclipse.emf.cdo.util.InvalidURIException: Invalid URI "cdo://1ff5d226-b1f0-40fb-aba2-0c31b38c764f": java.lang.IllegalStateException: Different object was registered for OID1

I set a breakpoint for both exceptions mentioned, caught and uncaught, in my CDOServer and it never gets hit despite the message telling me that is the cause of the problem? Confused.

Can you explain what to look for in the database tables that will allow me to reset the object for OID1 to the correct object?

Also while you are at it, one of our other unsolved CDO exceptions is the ClassCastException, Since you have responded to this thread I will try to engage you here

Daemon Thread [net4j-Thread-1] (Suspended (exception ClassCastException))	
	CDOIDObjectLongImpl.doCompareTo(CDOID) line: 112	
	CDOIDObjectLongImpl(AbstractCDOID).compareTo(CDOID) line: 96	
	CDOIDObjectLongImpl(AbstractCDOID).compareTo(Object) line: 1	
	LongIDHandler.compare(CDOID, CDOID) line: 85	
	LongIDHandler.compare(Object, Object) line: 1	
	DBStoreAccessor.applyIDMappings(InternalCommitContext, OMMonitor) line: 493	
	DBStoreAccessor(StoreAccessor).doWrite(InternalCommitContext, OMMonitor) line: 89	
	DBStoreAccessor(StoreAccessorBase).write(InternalCommitContext, OMMonitor) line: 150	
	TransactionCommitContext.write(OMMonitor) line: 612	
	InternalCommitContext$1.runLoop(int, InternalCommitContext, OMMonitor) line: 46	
	InternalCommitContext$1.runLoop(int, Object, OMMonitor) line: 1	
	Store$1(ProgressDistributor).run(ProgressDistributable<CONTEXT>[], CONTEXT, OMMonitor) line: 96	
	Repository$Default(Repository).commitUnsynced(InternalCommitContext, OMMonitor) line: 993	
	Repository$Default(Repository).commit(InternalCommitContext, OMMonitor) line: 986	
	CommitTransactionIndication.indicatingCommit(OMMonitor) line: 315	
	CommitTransactionIndication.indicating(CDODataInput, OMMonitor) line: 100	
	CommitTransactionIndication(CDOServerIndicationWithMonitoring).indicating(ExtendedDataInputStream, OMMonitor) line: 110	
	CommitTransactionIndication(IndicationWithMonitoring).indicating(ExtendedDataInputStream) line: 87	
	CommitTransactionIndication(IndicationWithResponse).doExtendedInput(ExtendedDataInputStream) line: 92	
	CommitTransactionIndication(Signal).doInput(BufferInputStream) line: 328	
	CommitTransactionIndication(IndicationWithResponse).execute(BufferInputStream, BufferOutputStream) line: 65	
	CommitTransactionIndication(IndicationWithMonitoring).execute(BufferInputStream, BufferOutputStream) line: 66	
	CommitTransactionIndication(Signal).runSync() line: 253	
	CommitTransactionIndication(Signal).run() line: 149	
	ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1145	
	ThreadPoolExecutor$Worker.run() line: 615	
	Thread.run() line: 724

The maxId here DBStoreAccessor.applyIDMappings is a CDONullIDImpl and thus the comparison fails. This look like a bug in CDO to me, will dig further before I raise a bugzilla

Re: Exception during CDO commit [message #1421578 is a reply to message #1421542]

Thu, 11 September 2014 11:06

Eclipse User

I am further along, but no where nearing understanding the problem. I had a look at the model being saved in the client, it is small repo in fact here are the references in the CDOResourceImpl$ContentCDOList instance just before I save.
[Product@OID3, File@OID4, Database@OID6, Feed@OID14[DIRTY], Record@oid3[NEW]]

As you can see I simply added a Record model object and the reference from the Feed model object to that new Record is updated.
Trouble is I cannot find the actual Record instance in the CDOResourceImpl$ContentCDOList. I assume it uses this reference to look them up from somewhere deep in the CDOResourceImpl. I'd like to see it's field members and how they are populated. Any pointers on this structure?

Thx

[Updated on: Thu, 11 September 2014 11:07] by Moderator

Re: Exception during CDO commit [message #1421582 is a reply to message #1421578]

Thu, 11 September 2014 11:12

Eclipse User

Just noticed that the oid3 on the Record is lowercase "oid" when all the others are uppercase, wonder if that is significant. Feel free to jump in here any CDO experts.

Re: Exception during CDO commit [message #1421590 is a reply to message #1421582]

Thu, 11 September 2014 11:28

Eclipse User

Am 11.09.2014 um 17:12 schrieb David Wynter:
> Just noticed that the oid3 on the Record is lowercase "oid" when all the others are uppercase, wonder if that is
> significant. Feel free to jump in here any CDO experts.
The lowercase "oid" indicates that the object is NEW (uncommitted) and still has a temporary (local) CDOID. As part of
the subsequent commit process it should be replaced with a permanent CDOID as assigned by the server. All mappings from
temp IDs to permanent IDs are returned in the commit response and applied to all local objects.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Previous Topic:	[EDAPT] Issue when using 'load resource'
Next Topic:	Ecore Tools and Ecore digram in eclipse Luna

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Apr 27 04:23:52 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter