Fix for 2615 : deadlock in changelog trimming

gbellato

04.11.2007 62e49b07a6198f230f931016de063a21cbca6e88

Fix for 2615  : deadlock in changelog trimming

When the changelog trimming meet a database Exception, it tries to close the DB
on which the problem happens.
Unfortunately the close waits for the trim thread to complete before returning.
We therefore end in a situation where trim thread deadlock itself.
Since it is also holding other locks at this point it causes a dealock of the whole
Replication Server.

The solution is simply to break the loop.

After this fix we still have to find the reason for the DB Exception.

 opends/src/server/org/opends/server/replication/server/DbHandler.java

@@ -89,7 +89,7 @@
  private boolean done = false;
  private DirectoryThread thread = null;
  private Object flushLock = new Object();
  private ReplicationDbEnv dbenv;
  private ReplicationServer replicationServer;


  // The High and low water mark for the max size of the msgQueue.
@@ -122,7 +122,6 @@
      ReplicationDbEnv dbenv, long generationId)
         throws DatabaseException
  {
    this.dbenv = dbenv;
    this.serverId = id;
    this.baseDn = baseDn;
    this.trimage = replicationServer.getTrimage();
@@ -314,6 +313,11 @@
   */
  public void shutdown()
  {
    if (shutdown == true)
    {
      return;
    }

    shutdown  = true;
    synchronized (this)
    {
@@ -365,6 +369,7 @@
        mb.append(ERR_EXCEPTION_CHANGELOG_TRIM_FLUSH.get());
        mb.append(stackTraceToSingleLineString(end));
        logError(mb.toMessage());
        replicationServer.shutdown();
        break;
      }
    }
@@ -424,6 +429,9 @@
      cursor.close();
    } catch (DatabaseException e)
    {
      // mark shutdown for this db so that we don't try again to
      // stop it from cursor.close() or methods called by cursor.close()
      shutdown = true;
      cursor.close();
      throw (e);
    }