• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • DSO:L1,DSO:L2
  • teck
  • Reporter: teck
  • January 30, 2007
  • 0
  • Watchers: 0
  • July 27, 2012
  • January 30, 2007


Exception in thread “WorkerThread(apply_changes_stage,0)” com.tc.util.TCAssertionError: Expected <1> but got <0> at com.tc.util.Assert.assertEquals(Assert.java:135) at com.tc.objectserver.managedobject.LiteralTypesManagedObjectState.apply(LiteralTypesManagedObjectState.java:44) at com.tc.objectserver.managedobject.ManagedObjectImpl.apply(ManagedObjectImpl.java:158) at com.tc.objectserver.tx.ServerTransactionManagerImpl.apply(ServerTransactionManagerImpl.java:163) at com.tc.objectserver.handler.ApplyTransactionChangeHandler.handleEvent(ApplyTransactionChangeHandler.java:77) at com.tc.async.impl.StageImpl$WorkerThread.run(StageImpl.java:141


Tim Eck 2007-01-30

The traverser for new shared objects will create TCObjects for literal instances referenced. That isn’t supposed to happen, but wasn’t causing a problem since ClientObjectManager never recorded the TCObject->pojo mapping (there is a isLiteralPojo() check in ClientObjectManager.basicAddLocal()). In this case, orphan TCObjects and corresponding state instances in the server were being created for non-primitive literals. When an enum class is instrumented (and more importantly acquires the Manageable interface), the code in basicAddLocal() does remember the TCObject mapping. This fact combined with racing txns leads one txn to dehydrate the literal, and the other to send a delta DNA containg zero actions, which produces the exception

Fix is change the traverser to not include literals.