Exception during CDO commit [message #1406353] |
Sat, 09 August 2014 20: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
[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 20:18] by Moderator Report message to a moderator
|
|
|
Re: Exception during CDO commit [message #1420016 is a reply to message #1406353] |
Tue, 09 September 2014 11: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 11:45] by Moderator Report message to a moderator
|
|
|
Re: Exception during CDO commit [message #1420037 is a reply to message #1420016] |
Tue, 09 September 2014 12: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 14: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 15: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 15:07] by Moderator Report message to a moderator
|
|
|
|
Re: Exception during CDO commit [message #1421590 is a reply to message #1421582] |
Thu, 11 September 2014 15: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
|
|
|
Powered by
FUDForum. Page generated in 0.04658 seconds