From 1cecbe50b7e18ecbbf431d729e892974984a22a1 Mon Sep 17 00:00:00 2001
From: gbellato <gbellato@localhost>
Date: Wed, 22 Apr 2009 14:00:34 +0000
Subject: [PATCH] Fix for 2977 : exception during the Replication Server database trimming
---
opends/src/server/org/opends/server/replication/server/ReplicationDbEnv.java | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/opends/src/server/org/opends/server/replication/server/ReplicationDbEnv.java b/opends/src/server/org/opends/server/replication/server/ReplicationDbEnv.java
index 98aa2ee..7506597 100644
--- a/opends/src/server/org/opends/server/replication/server/ReplicationDbEnv.java
+++ b/opends/src/server/org/opends/server/replication/server/ReplicationDbEnv.java
@@ -22,7 +22,7 @@
* CDDL HEADER END
*
*
- * Copyright 2006-2008 Sun Microsystems, Inc.
+ * Copyright 2006-2009 Sun Microsystems, Inc.
*/
package org.opends.server.replication.server;
import org.opends.messages.*;
@@ -89,9 +89,17 @@
envConfig.setAllowCreate(true);
envConfig.setTransactional(true);
envConfig.setConfigParam("je.cleaner.expunge", "true");
- // TODO : the DB cache size should be configurable
- // For now set 5M is OK for being efficient in 64M total for the JVM
+
+ // Tests have shown that since the parsing of the Replication log is always
+ // done sequentially, it is not necessary to use a large DB cache.
+ // Use 5M so that the replication can be used with 64M total for the JVM.
envConfig.setConfigParam("je.maxMemory", "5000000");
+
+ // Since records are always added at the end of the Replication log and
+ // deleted at the beginning of the Replication log, this should never
+ // cause any deadlock. It is therefore safe to increase the TXN timeout
+ // to 10 seconds.
+ envConfig.setTxnTimeout(10000000);
dbEnvironment = new Environment(new File(path), envConfig);
/*
--
Gitblit v1.10.0