fix for 1898 : Conflicts between moddn and del generate server errors

gbellato

06.06.2007 02e99b85ec86120b3d40584719bf16dff8d99cde

 opendj-sdk/opends/src/server/org/opends/server/replication/plugin/ReplicationDomain.java

@@ -1612,6 +1612,17 @@
  // get the current DN of this entry in the database.
  DN currentDN = findEntryDN(entryUid);

  if (currentDN == null)
  {
    // The entry targetted by the Modify DN is not in the database
    // anymore.
    // This is a conflict between a delete and this modify DN.
    // The entry has been deleted anymore so we can safely assume
    // that the operation is completed.
    numResolvedNamingConflicts.incrementAndGet();
    return true;
  }

  // if the newDN and the current DN match then the operation
  // is a no-op (this was probably a second replay)
  // don't do anything.

 opendj-sdk/opends/tests/unit-tests-testng/src/server/org/opends/server/replication/UpdateOperationTest.java

@@ -1089,6 +1089,23 @@
    // check that unresolved conflict count has been incremented
    assertEquals(getMonitorDelta(), 1);
    
    // Check that when an entry is deleted on a first master and
    // renamed on a second master and the rename is replayed last
    // this is correctly detected as a resolved conflict.
    // To simulate this simply try a modifyDN on a non existent uid.
    modDnMsg = new ModifyDNMsg(
        "uid=new person,ou=People,dc=example,dc=com", gen.newChangeNumber(),
        "33343333-3533-3633-3373-333333833333", baseUUID, false,
        "uid=wrong, ou=people,dc=example,dc=com",
        "uid=newrdn");
    updateMonitorCount(baseDn, resolvedMonitorAttr);
    broker.publish(modDnMsg);
    // unfortunately it is difficult to check that the operation
    // did not do anything.
    // The only thing we can check is that resolved naminf conflict counter
    // has correctly been incremented.
    assertEquals(getMonitorDelta(), 1);
    
    broker.stop();
  }