Community
Participate
Working Groups
Build Identifier: From time to time I'm getting exception like this: java.lang.IllegalArgumentException: revision=CDOResource@OID:http://www.eclipse.org/emf/CDO/Eresource/2.0.0#CDOResource#1:0v23, created=2010-12-29 14:40:26:570, revised=1970-01-01 00:59:59:999 at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.setRevised(BaseCDORevision.java:327) at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.addRevision(CDORevisionManagerImpl.java:406) at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevisionByVersion(CDORevisionManagerImpl.java:224) at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.isContainerLocked(TransactionCommitContext.java:781) at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockObjects(TransactionCommitContext.java:718) at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:388) at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:40) at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1) at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:96) at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:233) at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:90) at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109) at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:84) at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:90) at org.eclipse.net4j.signal.Signal.doInput(Signal.java:316) at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:63) at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:63) at org.eclipse.net4j.signal.Signal.runSync(Signal.java:241) at org.eclipse.net4j.signal.Signal.run(Signal.java:147) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Here revised == -1 which is a consequence of this line in CDORevisionManagerImpl: oldRevision.setRevised(revision.getTimeStamp() - 1); Looking at javadoc of CDOBranchPoint.getTimestamp() it seems that it is ok for getTimestamp() to return 0. So my guess is that some additional checks might be needed in CDORevisionManagerImpl (but I don't really now). I'm using latest milestone of CDO 4. Reproducible: Sometimes Steps to Reproduce: I haven't really tried to find exact steps required to reproduce it, but I might do that if the above exception turns out to be insufficient.
This one is hard to reproduce. It can eventually occur if two clients commit tree structure changes at the same time, possibly trying to cause containment cycles. Changing the order of adjustForCommit() and lockObject() in TransactionCommitContext.write() should fix this by ensuring that the created timestamp of revisions is set when the RevisionManager tries to load and revise old revisions. Patch coming...
Created attachment 185935 [details] Patch v1 - for future reference
Committed to HEAD
> It can eventually occur if two clients commit tree structure changes > at the same time, possibly trying to cause containment cycles. I didn't thought I had any of these :) > Changing the order of adjustForCommit() and lockObject() in > TransactionCommitContext.write() should fix this by ensuring that > the created timestamp of revisions is set when the RevisionManager > tries to load and revise old revisions. Patch coming... Thanks, I'll test it and post here if the problem occurs again.
I had to undo this fix because it caused a regression of bug 299897.
Investigating a new fix...
I must admit that I have no clue why this can happen. Clear so far: - During the containment cycle check in lockObjects() the revisionManager is asked to provide a revision (is it just accidentally the root resource??). - That revision is not cached but loaded from the IStore. - The loaded revision is added to the revision cache - The cache detects tat the previous revision is already cached and tries to "revise" it, i.e.: oldRevision.setRevised(newRevision.getTimeStamp() - 1); According to the exception message the new revision has a zero timestamp. But that should not happen as it was just loaded from the store and no persistent revision must hav a zero creation timestamp. The best I can do for now, I've added an extra check against zero timestamps. Michal: 1) Are you modyfing the backend data, bypassing CDO? 2) When this issue occurs again, can you check that the backend data is correct (dump db, etc.)? 3) Are you using repository replication? 4) For now I'm closing this as WORKSFORME. Please reopen if this happens again...
> 1) Are you modyfing the backend data, bypassing CDO? No, I don't. 2) When this issue occurs again, can you check that the backend data is correct (dump db, etc.)? Sure, if I manage to catch it again of course. 3) Are you using repository replication? No. 4) For now I'm closing this as WORKSFORME. Please reopen if this happens again... OK.
