mirror of https://github.com/apache/cassandra
merge from 0.7
git-svn-id: https://svn.apache.org/repos/asf/cassandra/trunk@1053717 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
commit
592970a87b
|
|
@ -23,6 +23,9 @@
|
|||
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)
|
||||
* large row support for SSTableExport (CASSANDRA-1867)
|
||||
* examine the right nibble when validating TimeUUID (CASSANDRA-1910)
|
||||
|
||||
|
||||
0.7.0-rc3
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
# any class that implements the SeedProvider interface and has a constructor that takes a Map<String, String> of
|
||||
# parameters will do.
|
||||
|
|
|
|||
|
|
@ -106,8 +106,7 @@ public class Config
|
|||
|
||||
public static enum CommitLogSync {
|
||||
periodic,
|
||||
batch,
|
||||
periodic_without_flush
|
||||
batch
|
||||
}
|
||||
|
||||
public static enum DiskAccessMode {
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
@ -512,10 +511,6 @@ public class CommitLog
|
|||
sync();
|
||||
segments.add(new CommitLogSegment());
|
||||
}
|
||||
else if (flushEachWrite)
|
||||
{
|
||||
currentSegment().flush();
|
||||
}
|
||||
}
|
||||
catch (IOException e)
|
||||
{
|
||||
|
|
|
|||
|
|
@ -130,11 +130,6 @@ public class CommitLogSegment
|
|||
logWriter.sync();
|
||||
}
|
||||
|
||||
public void flush() throws IOException
|
||||
{
|
||||
logWriter.flush();
|
||||
}
|
||||
|
||||
public CommitLogContext getContext()
|
||||
{
|
||||
return new CommitLogContext(logWriter.getFilePointer());
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ public class TimeUUIDType extends AbstractType
|
|||
if (bytes.remaining() > 0)
|
||||
{
|
||||
slice.position(6);
|
||||
if ((slice.get() & 0x0f) != 1)
|
||||
if ((slice.get() & 0xf0) != 0x10)
|
||||
throw new MarshalException("Invalid version for TimeUUID type.");
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -98,4 +98,22 @@ public class TimeUUIDTypeTest
|
|||
assert i0 <= i1;
|
||||
}
|
||||
}
|
||||
|
||||
@Test
|
||||
public void testValidTimeVersion()
|
||||
{
|
||||
java.util.UUID uuid1 = java.util.UUID.fromString("00000000-0000-1000-0000-000000000000");
|
||||
assert uuid1.version() == 1;
|
||||
timeUUIDType.validate(ByteBuffer.wrap(UUIDGen.decompose(uuid1)));
|
||||
}
|
||||
|
||||
@Test(expected = MarshalException.class)
|
||||
public void testInvalidTimeVersion()
|
||||
{
|
||||
java.util.UUID uuid2 = java.util.UUID.fromString("00000000-0000-2100-0000-000000000000");
|
||||
assert uuid2.version() == 2;
|
||||
timeUUIDType.validate(ByteBuffer.wrap(UUIDGen.decompose(uuid2)));
|
||||
}
|
||||
|
||||
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue