Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 333307

Summary: IllegalArgumentException: revised == -1
Product: [Modeling] EMF Reporter: Michal Tkacz <Michal.Tkacz>
Component: cdo.coreAssignee: Eike Stepper <stepper>
Status: CLOSED WORKSFORME QA Contact: Eike Stepper <stepper>
Severity: normal    
Priority: P3 CC: martin.fluegge
Version: 4.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 299897    
Attachments:
Description Flags
Patch v1 - for future reference none

Description Michal Tkacz CLA 2010-12-29 10:31:16 EST 
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.
Comment 1 Eike Stepper CLA 2011-01-02 07:06:05 EST 
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...
Comment 2 Eike Stepper CLA 2011-01-02 07:06:28 EST 
Created attachment 185935 [details]
Patch v1 - for future reference
Comment 3 Eike Stepper CLA 2011-01-02 07:06:42 EST 
Committed to HEAD
Comment 4 Michal Tkacz CLA 2011-01-03 03:33:28 EST 
> 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.
Comment 5 Eike Stepper CLA 2011-01-05 07:36:49 EST 
I had to undo this fix because it caused a regression of bug 299897.
Comment 6 Eike Stepper CLA 2011-01-05 07:37:03 EST 
Investigating a new fix...
Comment 7 Eike Stepper CLA 2011-01-05 10:05:57 EST 
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...
Comment 8 Michal Tkacz CLA 2011-01-05 15:15:14 EST 
> 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.