revert #1780 for CASSANDRA-1917

git-svn-id: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7.0@1053710 13f79535-47bb-0310-9956-ffa450edef68

CHANGES.txt

@@ -11,6 +11,7 @@ dev
    replication Strategies
  * increased amount of index locks for faster commitlog replay
  * collect secondary index tombstones immediately (CASSANDRA-1914)
+ * revert commitlog changes from #1780 (CASSANDRA-1917)
 
 
 0.7.0-rc3

conf/cassandra.yaml

@@ -61,32 +61,17 @@ saved_caches_directory: /var/lib/cassandra/saved_caches
 # Size to allow commitlog to grow to before creating a new segment 
 commitlog_rotation_threshold_in_mb: 128
 
-# commitlog_sync supports the following modes:
-# 
-# batch:
-# In batch mode, Cassandra won't ack writes until the commit log
-# has been fsynced to disk.  But fsyncing each write at once is
-# performance-prohibitive, so instead Cassandra will wait up to
-# commitlog_sync_batch_window_in_ms milliseconds for other writes, before
-# syncing that "batch" at once.  This causes a performance penalty
-# of about 15% when the commitlog is on a separate device, and much more
-# when it shares the same device as the data files.
-#
-# periodic:
-# Writes may be acked immediately (without waiting for the commitlog
-# append) and the CommitLog is simply synced every
-# commitlog_sync_period_in_ms milliseconds.
-#
-# periodic_without_flush:
-# Like periodic, but the commitlog write buffer is only flushed
-# before the sync, so any interruption to the process can be
-# expected to lose some writes.  This is the old 0.6 periodic
-# behavior and will be removed in future versions if testing
-# continues to show no performance benefit over normal periodic.
+# commitlog_sync may be either "periodic" or "batch." 
+# When in batch mode, Cassandra won't ack writes until the commit log
+# has been fsynced to disk.  It will wait up to
+# CommitLogSyncBatchWindowInMS milliseconds for other writes, before
+# performing the sync.
 commitlog_sync: periodic
+
+# the other option is "timed," where writes may be acked immediately
+# and the CommitLog is simply synced every commitlog_sync_period_in_ms
+# milliseconds.
 commitlog_sync_period_in_ms: 10000
-# commitlog_sync: batch
-# commitlog_sync_batch_window_in_ms: 10
 
 # Addresses of hosts that are deemed contact points.
 # Cassandra nodes use this list of hosts to find each other and learn

src/java/org/apache/cassandra/config/Config.java

@@ -105,8 +105,7 @@ public class Config
     
     public static enum CommitLogSync {
         periodic,
-        batch,
-        periodic_without_flush
+        batch
     }
     
     public static enum DiskAccessMode {

src/java/org/apache/cassandra/db/commitlog/CommitLog.java

@@ -491,7 +491,6 @@ public class CommitLog
 
     // TODO this should be a Runnable since it doesn't actually return anything, but it's difficult to do that
     // without breaking the fragile CheaterFutureTask in BatchCLES.
-    final static boolean flushEachWrite = DatabaseDescriptor.getCommitLogSync() == Config.CommitLogSync.periodic;
     class LogRecordAdder implements Callable, Runnable
     {
         final RowMutation rowMutation;
@@ -514,10 +513,6 @@ public class CommitLog
                     sync();
                     segments.add(new CommitLogSegment());
                 }
-                else if (flushEachWrite)
-                {
-                    currentSegment().flush();
-                }
             }
             catch (IOException e)
             {

src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java

@@ -140,11 +140,6 @@ public class CommitLogSegment
         logWriter.sync();
     }
 
-    public void flush() throws IOException
-    {
-        logWriter.flush();
-    }
-
     public CommitLogContext getContext()
     {
         return new CommitLogContext(logWriter.getFilePointer());