[1/6] cassandra git commit: Fix full ring range subtraction
Repository: cassandra Updated Branches: refs/heads/cassandra-3.0 60a8cfe11 -> c6f822c2a refs/heads/cassandra-3.11 2ed7c6a6b -> 78c7d57eb refs/heads/trunk 521542ff2 -> 131080371 Fix full ring range subtraction Patch by Aleksandr Sorokoumov; reviewed by Alex Petrov for CASSANDRA-14869 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c6f822c2 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c6f822c2 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c6f822c2 Branch: refs/heads/cassandra-3.0 Commit: c6f822c2a07e0e7c8e4af72523fe62d181c71e56 Parents: 60a8cfe Author: Aleksandr Sorokoumov Authored: Tue Nov 6 21:47:03 2018 +0100 Committer: Alex Petrov Committed: Mon Nov 19 08:51:56 2018 +0100 -- src/java/org/apache/cassandra/dht/Range.java| 27 +++-- .../org/apache/cassandra/dht/RangeTest.java | 40 2 files changed, 63 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6f822c2/src/java/org/apache/cassandra/dht/Range.java -- diff --git a/src/java/org/apache/cassandra/dht/Range.java b/src/java/org/apache/cassandra/dht/Range.java index ba6854e..3cf292a 100644 --- a/src/java/org/apache/cassandra/dht/Range.java +++ b/src/java/org/apache/cassandra/dht/Range.java @@ -256,6 +256,14 @@ public class Range> extends AbstractBounds implemen } /** + * Tells if the given range covers the entire ring + */ +private static > boolean isFull(T left, T right) +{ +return left.equals(right); +} + +/** * Note: this class has a natural ordering that is inconsistent with equals */ public int compareTo(Range rhs) @@ -274,13 +282,24 @@ public class Range> extends AbstractBounds implemen * Subtracts a portion of this range. * @param contained The range to subtract from this. It must be totally * contained by this range. - * @return An ArrayList of the Ranges left after subtracting contained + * @return A List of the Ranges left after subtracting contained * from this. */ -private ArrayList> subtractContained(Range contained) +private List> subtractContained(Range contained) { -ArrayList> difference = new ArrayList>(2); +// both ranges cover the entire ring, their difference is an empty set +if(isFull(left, right) && isFull(contained.left, contained.right)) +{ +return Collections.emptyList(); +} + +// a range is subtracted from another range that covers the entire ring +if(isFull(left, right)) +{ +return Collections.singletonList(new Range<>(contained.right, contained.left)); +} +List> difference = new ArrayList<>(2); if (!left.equals(contained.left)) difference.add(new Range(left, contained.left)); if (!right.equals(contained.right)) @@ -346,7 +365,7 @@ public class Range> extends AbstractBounds implemen // intersections.length must be 2 Range first = intersections[0]; Range second = intersections[1]; -ArrayList> temp = rhs.subtractContained(first); +List> temp = rhs.subtractContained(first); // Because there are two intersections, subtracting only one of them // will yield a single Range. http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6f822c2/test/unit/org/apache/cassandra/dht/RangeTest.java -- diff --git a/test/unit/org/apache/cassandra/dht/RangeTest.java b/test/unit/org/apache/cassandra/dht/RangeTest.java index 5cd94e2..627253d 100644 --- a/test/unit/org/apache/cassandra/dht/RangeTest.java +++ b/test/unit/org/apache/cassandra/dht/RangeTest.java @@ -362,6 +362,8 @@ public class RangeTest assertRanges(range.subtractAll(collection), 10L, 54L, 60L, 90L); collection.add(makeRange(80L, 95L)); assertRanges(range.subtractAll(collection), 10L, 54L, 60L, 80L); + +assertEquals(Collections.emptySet(), range.subtractAll(Collections.singleton(range))); } @Test @@ -380,6 +382,44 @@ public class RangeTest assertRanges(range.subtractAll(collection), 100L, 200L, 500L, 0L); collection.add(makeRange(1000L, 0)); assertRanges(range.subtractAll(collection), 100L, 200L, 500L, 1000L); + +assertEquals(Collections.emptySet(), range.subtractAll(Collections.singleton(range))); +} + +@Test +public void testSubtractAllFromFullRingRange() +{ +Range ring1 = makeRange(50L, 50L); +Range ring2 = makeRange(0L, 0L); + +Set> co
[3/6] cassandra git commit: Fix full ring range subtraction
Fix full ring range subtraction Patch by Aleksandr Sorokoumov; reviewed by Alex Petrov for CASSANDRA-14869 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c6f822c2 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c6f822c2 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c6f822c2 Branch: refs/heads/trunk Commit: c6f822c2a07e0e7c8e4af72523fe62d181c71e56 Parents: 60a8cfe Author: Aleksandr Sorokoumov Authored: Tue Nov 6 21:47:03 2018 +0100 Committer: Alex Petrov Committed: Mon Nov 19 08:51:56 2018 +0100 -- src/java/org/apache/cassandra/dht/Range.java| 27 +++-- .../org/apache/cassandra/dht/RangeTest.java | 40 2 files changed, 63 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6f822c2/src/java/org/apache/cassandra/dht/Range.java -- diff --git a/src/java/org/apache/cassandra/dht/Range.java b/src/java/org/apache/cassandra/dht/Range.java index ba6854e..3cf292a 100644 --- a/src/java/org/apache/cassandra/dht/Range.java +++ b/src/java/org/apache/cassandra/dht/Range.java @@ -256,6 +256,14 @@ public class Range> extends AbstractBounds implemen } /** + * Tells if the given range covers the entire ring + */ +private static > boolean isFull(T left, T right) +{ +return left.equals(right); +} + +/** * Note: this class has a natural ordering that is inconsistent with equals */ public int compareTo(Range rhs) @@ -274,13 +282,24 @@ public class Range> extends AbstractBounds implemen * Subtracts a portion of this range. * @param contained The range to subtract from this. It must be totally * contained by this range. - * @return An ArrayList of the Ranges left after subtracting contained + * @return A List of the Ranges left after subtracting contained * from this. */ -private ArrayList> subtractContained(Range contained) +private List> subtractContained(Range contained) { -ArrayList> difference = new ArrayList>(2); +// both ranges cover the entire ring, their difference is an empty set +if(isFull(left, right) && isFull(contained.left, contained.right)) +{ +return Collections.emptyList(); +} + +// a range is subtracted from another range that covers the entire ring +if(isFull(left, right)) +{ +return Collections.singletonList(new Range<>(contained.right, contained.left)); +} +List> difference = new ArrayList<>(2); if (!left.equals(contained.left)) difference.add(new Range(left, contained.left)); if (!right.equals(contained.right)) @@ -346,7 +365,7 @@ public class Range> extends AbstractBounds implemen // intersections.length must be 2 Range first = intersections[0]; Range second = intersections[1]; -ArrayList> temp = rhs.subtractContained(first); +List> temp = rhs.subtractContained(first); // Because there are two intersections, subtracting only one of them // will yield a single Range. http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6f822c2/test/unit/org/apache/cassandra/dht/RangeTest.java -- diff --git a/test/unit/org/apache/cassandra/dht/RangeTest.java b/test/unit/org/apache/cassandra/dht/RangeTest.java index 5cd94e2..627253d 100644 --- a/test/unit/org/apache/cassandra/dht/RangeTest.java +++ b/test/unit/org/apache/cassandra/dht/RangeTest.java @@ -362,6 +362,8 @@ public class RangeTest assertRanges(range.subtractAll(collection), 10L, 54L, 60L, 90L); collection.add(makeRange(80L, 95L)); assertRanges(range.subtractAll(collection), 10L, 54L, 60L, 80L); + +assertEquals(Collections.emptySet(), range.subtractAll(Collections.singleton(range))); } @Test @@ -380,6 +382,44 @@ public class RangeTest assertRanges(range.subtractAll(collection), 100L, 200L, 500L, 0L); collection.add(makeRange(1000L, 0)); assertRanges(range.subtractAll(collection), 100L, 200L, 500L, 1000L); + +assertEquals(Collections.emptySet(), range.subtractAll(Collections.singleton(range))); +} + +@Test +public void testSubtractAllFromFullRingRange() +{ +Range ring1 = makeRange(50L, 50L); +Range ring2 = makeRange(0L, 0L); + +Set> contained1 = Collections.singleton(makeRange(10L, 100L)); +Set> contained2 = Collections.singleton(makeRange(100L, 10L)); + +assertEquals(contained2, ring1.subtractAll(contained
[2/6] cassandra git commit: Fix full ring range subtraction
Fix full ring range subtraction Patch by Aleksandr Sorokoumov; reviewed by Alex Petrov for CASSANDRA-14869 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c6f822c2 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c6f822c2 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c6f822c2 Branch: refs/heads/cassandra-3.11 Commit: c6f822c2a07e0e7c8e4af72523fe62d181c71e56 Parents: 60a8cfe Author: Aleksandr Sorokoumov Authored: Tue Nov 6 21:47:03 2018 +0100 Committer: Alex Petrov Committed: Mon Nov 19 08:51:56 2018 +0100 -- src/java/org/apache/cassandra/dht/Range.java| 27 +++-- .../org/apache/cassandra/dht/RangeTest.java | 40 2 files changed, 63 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6f822c2/src/java/org/apache/cassandra/dht/Range.java -- diff --git a/src/java/org/apache/cassandra/dht/Range.java b/src/java/org/apache/cassandra/dht/Range.java index ba6854e..3cf292a 100644 --- a/src/java/org/apache/cassandra/dht/Range.java +++ b/src/java/org/apache/cassandra/dht/Range.java @@ -256,6 +256,14 @@ public class Range> extends AbstractBounds implemen } /** + * Tells if the given range covers the entire ring + */ +private static > boolean isFull(T left, T right) +{ +return left.equals(right); +} + +/** * Note: this class has a natural ordering that is inconsistent with equals */ public int compareTo(Range rhs) @@ -274,13 +282,24 @@ public class Range> extends AbstractBounds implemen * Subtracts a portion of this range. * @param contained The range to subtract from this. It must be totally * contained by this range. - * @return An ArrayList of the Ranges left after subtracting contained + * @return A List of the Ranges left after subtracting contained * from this. */ -private ArrayList> subtractContained(Range contained) +private List> subtractContained(Range contained) { -ArrayList> difference = new ArrayList>(2); +// both ranges cover the entire ring, their difference is an empty set +if(isFull(left, right) && isFull(contained.left, contained.right)) +{ +return Collections.emptyList(); +} + +// a range is subtracted from another range that covers the entire ring +if(isFull(left, right)) +{ +return Collections.singletonList(new Range<>(contained.right, contained.left)); +} +List> difference = new ArrayList<>(2); if (!left.equals(contained.left)) difference.add(new Range(left, contained.left)); if (!right.equals(contained.right)) @@ -346,7 +365,7 @@ public class Range> extends AbstractBounds implemen // intersections.length must be 2 Range first = intersections[0]; Range second = intersections[1]; -ArrayList> temp = rhs.subtractContained(first); +List> temp = rhs.subtractContained(first); // Because there are two intersections, subtracting only one of them // will yield a single Range. http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6f822c2/test/unit/org/apache/cassandra/dht/RangeTest.java -- diff --git a/test/unit/org/apache/cassandra/dht/RangeTest.java b/test/unit/org/apache/cassandra/dht/RangeTest.java index 5cd94e2..627253d 100644 --- a/test/unit/org/apache/cassandra/dht/RangeTest.java +++ b/test/unit/org/apache/cassandra/dht/RangeTest.java @@ -362,6 +362,8 @@ public class RangeTest assertRanges(range.subtractAll(collection), 10L, 54L, 60L, 90L); collection.add(makeRange(80L, 95L)); assertRanges(range.subtractAll(collection), 10L, 54L, 60L, 80L); + +assertEquals(Collections.emptySet(), range.subtractAll(Collections.singleton(range))); } @Test @@ -380,6 +382,44 @@ public class RangeTest assertRanges(range.subtractAll(collection), 100L, 200L, 500L, 0L); collection.add(makeRange(1000L, 0)); assertRanges(range.subtractAll(collection), 100L, 200L, 500L, 1000L); + +assertEquals(Collections.emptySet(), range.subtractAll(Collections.singleton(range))); +} + +@Test +public void testSubtractAllFromFullRingRange() +{ +Range ring1 = makeRange(50L, 50L); +Range ring2 = makeRange(0L, 0L); + +Set> contained1 = Collections.singleton(makeRange(10L, 100L)); +Set> contained2 = Collections.singleton(makeRange(100L, 10L)); + +assertEquals(contained2, ring1.subtractAll(
[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk
Merge branch 'cassandra-3.11' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/13108037 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/13108037 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/13108037 Branch: refs/heads/trunk Commit: 13108037177a30e103a84bca5dadb38d1c090453 Parents: 521542f 78c7d57 Author: Alex Petrov Authored: Mon Nov 19 08:57:14 2018 +0100 Committer: Alex Petrov Committed: Mon Nov 19 08:57:14 2018 +0100 -- src/java/org/apache/cassandra/dht/Range.java| 27 +++-- .../org/apache/cassandra/dht/RangeTest.java | 40 2 files changed, 63 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/13108037/src/java/org/apache/cassandra/dht/Range.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/13108037/test/unit/org/apache/cassandra/dht/RangeTest.java -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11
Merge branch 'cassandra-3.0' into cassandra-3.11 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/78c7d57e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/78c7d57e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/78c7d57e Branch: refs/heads/trunk Commit: 78c7d57ebb28ac688cd287d7d8b8f483a99d0135 Parents: 2ed7c6a c6f822c Author: Alex Petrov Authored: Mon Nov 19 08:52:59 2018 +0100 Committer: Alex Petrov Committed: Mon Nov 19 08:52:59 2018 +0100 -- src/java/org/apache/cassandra/dht/Range.java| 27 +++-- .../org/apache/cassandra/dht/RangeTest.java | 40 2 files changed, 63 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/78c7d57e/src/java/org/apache/cassandra/dht/Range.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/78c7d57e/test/unit/org/apache/cassandra/dht/RangeTest.java -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11
Merge branch 'cassandra-3.0' into cassandra-3.11 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/78c7d57e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/78c7d57e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/78c7d57e Branch: refs/heads/cassandra-3.11 Commit: 78c7d57ebb28ac688cd287d7d8b8f483a99d0135 Parents: 2ed7c6a c6f822c Author: Alex Petrov Authored: Mon Nov 19 08:52:59 2018 +0100 Committer: Alex Petrov Committed: Mon Nov 19 08:52:59 2018 +0100 -- src/java/org/apache/cassandra/dht/Range.java| 27 +++-- .../org/apache/cassandra/dht/RangeTest.java | 40 2 files changed, 63 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/78c7d57e/src/java/org/apache/cassandra/dht/Range.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/78c7d57e/test/unit/org/apache/cassandra/dht/RangeTest.java -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14711) Apache Cassandra 3.2 crashing with exception org.apache.cassandra.db.marshal.TimestampType.compareCustom
[ https://issues.apache.org/jira/browse/CASSANDRA-14711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14711: - Component/s: Core > Apache Cassandra 3.2 crashing with exception > org.apache.cassandra.db.marshal.TimestampType.compareCustom > > > Key: CASSANDRA-14711 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14711 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Saurabh >Priority: Major > Attachments: hs_err_pid32069.log > > > Hi Team, > I am using Apache Cassandra 3.2 with Java 1.8.0_161-b12.. > Issue: > Cassandra is continuously crashing with generating an HEAP dump log. There > are no errors reported in system.log OR Debug.log. > Exception in hs_err_PID.log: > # Problematic frame: > # J 8283 C2 > org.apache.cassandra.db.marshal.TimestampType.compareCustom(Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)I > (6 bytes) @ 0x2b7d3d417fb4 [0x2b7d3d417c80+0x334] > Java Threads: ( => current thread ) > 0x2b7da57924a0 JavaThread "MemtableReclaimMemory:52" daemon > [_thread_blocked, id=117880, stack(0x2b7d917ff000,0x2b7d9184)] > 0x2b7d39f6a9e0 JavaThread "PerDiskMemtableFlushWriter_0:52" daemon > [_thread_blocked, id=117879, stack(0x2b7e4ea94000,0x2b7e4ead5000)] > 0x2b7d39d0f520 JavaThread "MemtablePostFlush:53" daemon > [_thread_blocked, id=117878, stack(0x2b7e407dd000,0x2b7e4081e000)] > 0x2b7df31a9150 JavaThread "MemtableFlushWriter:52" daemon > [_thread_blocked, id=117877, stack(0x2b7e406d9000,0x2b7e4071a000)] > 0x2b7e53e60110 JavaThread "RMI TCP Connection(1795)-127.0.0.1" daemon > : > : > lot of threads in BLOCKED status > Other Threads: > 0x2b7d38de5ea0 VMThread [stack: 0x2b7d8208d000,0x2b7d8218d000] > [id=32098] > 0x2b7d38fa9de0 WatcherThread [stack: > 0x2b7d88ee9000,0x2b7d88fe9000] [id=32108] > VM state:not at safepoint (normal execution) > VM Mutex/Monitor currently owned by a thread: None > Heap: > garbage-first heap total 8388608K, used 6791168K [0x0003c000, > 0x0003c0404000, 0x0007c000) > region size 4096K, 785 young (3215360K), 55 survivors (225280K) > Metaspace used 40915K, capacity 42044K, committed 42368K, reserved 1087488K > class space used 4429K, capacity 4646K, committed 4736K, reserved 1048576K > Heap Regions: (Y=young(eden), SU=young(survivor), HS=humongous(starts), > HC=humongous(continues), CS=collection set, F=free, TS=gc time stamp, > PTAMS=previous top-at-mark-start, NTAMS=next top-at-mark-start) > AC 0 O TS 0 PTAMS 0x0003c040 NTAMS 0x0003c040 space 4096K, > 100% used [0x0003c000, 0x0003c040) > AC 0 O TS 0 PTAMS 0x0003c080 NTAMS 0x0003c080 space 4096K, > 100% used [0x0003c040, 0x0003c080) > AC 0 O TS 9 PTAMS 0x0003c080 NTAMS 0x0003c080 space 4096K, > 100% used [0x0003c080, 0x0003c0c0) > AC 0 O TS 11 PTAMS 0x0003c0c0 NTAMS 0x0003c0c0 space 4096K, > 100% used [0x0003c0c0, 0x0003c100) > AC 0 O TS 11 PTAMS 0x0003c100 NTAMS 0x0003c100 space 4096K, > 100% used [0x0003c100, 0x0003c140) > AC 0 O TS 11 PTAMS 0x0003c140 NTAMS 0x0003c140 space 4096K, > 100% used [0x0003c140, 0x0003c180) > : > : > lot of such messages -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13900) Massive GC suspension increase after updating to 3.0.14 from 2.1.18
[ https://issues.apache.org/jira/browse/CASSANDRA-13900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-13900: - Component/s: Core > Massive GC suspension increase after updating to 3.0.14 from 2.1.18 > --- > > Key: CASSANDRA-13900 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13900 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Thomas Steinmaurer >Priority: Blocker > Attachments: cassandra2118_vs_3014.jpg, cassandra3014_jfr_5min.jpg, > cassandra_3.11.0_min_memory_utilization.jpg > > > In short: After upgrading to 3.0.14 (from 2.1.18), we aren't able to process > the same incoming write load on the same infrastructure anymore. > We have a loadtest environment running 24x7 testing our software using > Cassandra as backend. Both, loadtest and production is hosted in AWS and do > have the same spec on the Cassandra-side, namely: > * 9x m4.xlarge > * 8G heap > * CMS (400MB newgen) > * 2TB EBS gp2 > * Client requests are entirely CQL > per node. We have a solid/constant baseline in loadtest at ~ 60% CPU cluster > AVG with constant, simulated load running against our cluster, using > Cassandra 2.1 for > 2 years now. > Recently we started to upgrade to 3.0.14 in this 9 node loadtest environment, > and basically, 3.0.14 isn't able to cope with the load anymore. No particular > special tweaks, memory settings/changes etc., all the same as in 2.1.18. We > also didn't upgrade sstables yet, thus the increase mentioned in the > screenshot is not related to any manually triggered maintenance operation > after upgrading to 3.0.14. > According to our monitoring, with 3.0.14, we see a *GC suspension time > increase by a factor of > 2*, of course directly correlating with an CPU > increase > 80%. See: attached screen "cassandra2118_vs_3014.jpg" > This all means that our incoming load against 2.1.18 is something, 3.0.14 > can't handle. So, we would need to either scale up (e.g. m4.xlarge => > m4.2xlarge) or scale out for being able to handle the same load, which is > cost-wise not an option. > Unfortunately I do not have Java Flight Recorder runs for 2.1.18 at the > mentioned load, but can provide JFR session for our current 3.0.14 setup. The > attached 5min JFR memory allocation area (cassandra3014_jfr_5min.jpg) shows > compaction being the top contributor for the captured 5min time-frame. Could > be by "accident" covering the 5min with compaction as top contributor only > (although mentioned simulated client load is attached), but according to > stack traces, we see new classes from 3.0, e.g. BTreeRow.searchIterator() > etc. popping up as top contributor, thus possibly new classes / data > structures are causing much more object churn now. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5836) Seed nodes should be able to bootstrap without manual intervention
[ https://issues.apache.org/jira/browse/CASSANDRA-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5836: Component/s: Lifecycle > Seed nodes should be able to bootstrap without manual intervention > -- > > Key: CASSANDRA-5836 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5836 > Project: Cassandra > Issue Type: Bug > Components: Lifecycle >Reporter: Bill Hathaway >Priority: Minor > > The current logic doesn't allow a seed node to be bootstrapped. If a user > wants to bootstrap a node configured as a seed (for example to replace a seed > node via replace_token), they first need to remove the node's own IP from the > seed list, and then start the bootstrap process. This seems like an > unnecessary step since a node never uses itself as a seed. > I think it would be a better experience if the logic was changed to allow a > seed node to bootstrap without manual intervention when there are other seed > nodes up in a ring. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5672) Add enumumerated column to system_trace.events table to signify the type of event.
[ https://issues.apache.org/jira/browse/CASSANDRA-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5672: Component/s: Observability > Add enumumerated column to system_trace.events table to signify the type of > event. > -- > > Key: CASSANDRA-5672 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5672 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Affects Versions: 1.2.0 >Reporter: Ryan McGuire >Priority: Minor > > Tracing of queries is useful for at least two different purposes: > * Interactively diagnosing a problem, via cqlsh, by a human. > * Programatically recording and responding to how queries behave. > This second purpose is not well suited to how the system_trace.events table > is currently organized, as the only identifying characteristic of each event > is a free-form string that can (and has) been changed in later versions. > [~jbellis] [mentioned the > possibility|http://www.datastax.com/dev/blog/advanced-request-tracing-in-cassandra-1-2] > of adding an enumeration of event types that would be immutable. > Reference [this > dtest|https://github.com/riptano/cassandra-dtest/pull/13/files] that parses > the strings in this table via regex. If these strings change, this test will > break. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-3830) gossip-to-seeds is not obviously independent of failure detection algorithm
[ https://issues.apache.org/jira/browse/CASSANDRA-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-3830: Component/s: Streaming and Messaging > gossip-to-seeds is not obviously independent of failure detection algorithm > > > Key: CASSANDRA-3830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3830 > Project: Cassandra > Issue Type: Task > Components: Distributed Metadata >Reporter: Peter Schuller >Assignee: Peter Schuller >Priority: Minor > > The failure detector, ignoring all the theory, boils down to an > extremely simple algorithm. The FD keeps track of a sliding window (of > 1000 currently) intervals of heartbeat for a given host. Meaning, we > have a track record of the last 1000 times we saw an updated heartbeat > for a host. > At any given moment, a host has a score which is simply the time since > the last heartbeat, over the *mean* interval in the sliding > window. For historical reasons a simple scaling factor is applied to > this prior to checking the phi conviction threshold. > (CASSANDRA-2597 has details, but thanks to Paul's work there it's now > trivial to understand what it does based on gut feeling) > So in effect, a host is considered down if we haven't heard from it in > some time which is significantly longer than the "average" time we > expect to hear from it. > This seems reasonable, but it does assume that under normal conditions > the average time between heartbeats does not change for reasons other > than those that would be plausible reasons to think a node is > unhealthy. > This assumption *could* be violated by the gossip-to-seed > feature. There is an argument to avoid gossip-to-seed for other > reasons (see CASSANDRA-3829), but this is a concrete case in which the > gossip-to-seed could cause a negative side-effect of the general kind > mentioned in CASSANDRA-3829 (see notes at end about not case w/o seeds > not being continuously tested). Normally, due to gossip to seed, > everyone essentially sees latest information within very few hart > beats (assuming only 2-3 seeds). But should all seeds be down, > suddenly we flip a switch and start relying on generalized propagation > in the gossip system, rather than the seed special case. > The potential problem I forese here is that if the average propagation > time suddenly spikes when all seeds become available, it could cause > bogus flapping of nodes into down state. > In order to test this, I deployeda ~ 180 node cluster with a version > that logs heartbet information on each interpret(), similar to: > INFO [GossipTasks:1] 2012-02-01 23:29:58,746 FailureDetector.java (line 187) > ep /XXX.XXX.XXX.XXX is at phi 0.0019521638443084342, last interval 7.0, mean > is 1557.27778 > It turns out that, at least at 180 nodes, with 4 seed nodes, whether > or not seeds are running *does not* seem to matter significantly. In > both cases, the mean interval is around 1500 milliseconds. > I don't feel I have a good grasp of whether this is incidental or > guaranteed, and it would be good to at least empirically test > propagation time w/o seeds at differnet cluster sizes; it's supposed > to be un-affected by cluster size ({{RING_DELAY}} is static for this > reason, is my understanding). Would be nice to see this be the case. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13365) Nodes entering GC loop, does not recover
[ https://issues.apache.org/jira/browse/CASSANDRA-13365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-13365: - Component/s: Core > Nodes entering GC loop, does not recover > > > Key: CASSANDRA-13365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13365 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: 34-node cluster over 4 DCs > Linux CentOS 7.2 x86 > Mix of 64GB/128GB RAM / node > Mix of 32/40 hardware threads / node, Xeon ~2.4Ghz > High read volume, low write volume, occasional sstable bulk loading >Reporter: Mina Naguib >Priority: Major > > Over the last week we've been observing two related problems affecting our > Cassandra cluster > Problem 1: 1-few nodes per DC entering GC loop, not recovering > Checking the heap usage stats, there's a sudden jump of 1-3GB. Some nodes > recover, but some don't and log this: > {noformat} > 2017-03-21T11:23:02.957-0400: 54099.519: [Full GC (Allocation Failure) > 13G->11G(14G), 29.4127307 secs] > 2017-03-21T11:23:45.270-0400: 54141.833: [Full GC (Allocation Failure) > 13G->12G(14G), 28.1561881 secs] > 2017-03-21T11:24:20.307-0400: 54176.869: [Full GC (Allocation Failure) > 13G->13G(14G), 27.7019501 secs] > 2017-03-21T11:24:50.528-0400: 54207.090: [Full GC (Allocation Failure) > 13G->13G(14G), 27.1372267 secs] > 2017-03-21T11:25:19.190-0400: 54235.752: [Full GC (Allocation Failure) > 13G->13G(14G), 27.0703975 secs] > 2017-03-21T11:25:46.711-0400: 54263.273: [Full GC (Allocation Failure) > 13G->13G(14G), 27.3187768 secs] > 2017-03-21T11:26:15.419-0400: 54291.981: [Full GC (Allocation Failure) > 13G->13G(14G), 26.9493405 secs] > 2017-03-21T11:26:43.399-0400: 54319.961: [Full GC (Allocation Failure) > 13G->13G(14G), 27.5222085 secs] > 2017-03-21T11:27:11.383-0400: 54347.945: [Full GC (Allocation Failure) > 13G->13G(14G), 27.1769581 secs] > 2017-03-21T11:27:40.174-0400: 54376.737: [Full GC (Allocation Failure) > 13G->13G(14G), 27.4639031 secs] > 2017-03-21T11:28:08.946-0400: 54405.508: [Full GC (Allocation Failure) > 13G->13G(14G), 30.3480523 secs] > 2017-03-21T11:28:40.117-0400: 54436.680: [Full GC (Allocation Failure) > 13G->13G(14G), 27.8220513 secs] > 2017-03-21T11:29:08.459-0400: 54465.022: [Full GC (Allocation Failure) > 13G->13G(14G), 27.4691271 secs] > 2017-03-21T11:29:37.114-0400: 54493.676: [Full GC (Allocation Failure) > 13G->13G(14G), 27.0275733 secs] > 2017-03-21T11:30:04.635-0400: 54521.198: [Full GC (Allocation Failure) > 13G->13G(14G), 27.1902627 secs] > 2017-03-21T11:30:32.114-0400: 54548.676: [Full GC (Allocation Failure) > 13G->13G(14G), 27.8872850 secs] > 2017-03-21T11:31:01.430-0400: 54577.993: [Full GC (Allocation Failure) > 13G->13G(14G), 27.1609706 secs] > 2017-03-21T11:31:29.024-0400: 54605.587: [Full GC (Allocation Failure) > 13G->13G(14G), 27.3635138 secs] > 2017-03-21T11:31:57.303-0400: 54633.865: [Full GC (Allocation Failure) > 13G->13G(14G), 27.4143510 secs] > 2017-03-21T11:32:25.110-0400: 54661.672: [Full GC (Allocation Failure) > 13G->13G(14G), 27.8595986 secs] > 2017-03-21T11:32:53.922-0400: 54690.485: [Full GC (Allocation Failure) > 13G->13G(14G), 27.5242543 secs] > 2017-03-21T11:33:21.867-0400: 54718.429: [Full GC (Allocation Failure) > 13G->13G(14G), 30.8930130 secs] > 2017-03-21T11:33:53.712-0400: 54750.275: [Full GC (Allocation Failure) > 13G->13G(14G), 27.6523013 secs] > 2017-03-21T11:34:21.760-0400: 54778.322: [Full GC (Allocation Failure) > 13G->13G(14G), 27.3030198 secs] > 2017-03-21T11:34:50.073-0400: 54806.635: [Full GC (Allocation Failure) > 13G->13G(14G), 27.1594154 secs] > 2017-03-21T11:35:17.743-0400: 54834.306: [Full GC (Allocation Failure) > 13G->13G(14G), 27.3766949 secs] > 2017-03-21T11:35:45.797-0400: 54862.360: [Full GC (Allocation Failure) > 13G->13G(14G), 27.5756770 secs] > 2017-03-21T11:36:13.816-0400: 54890.378: [Full GC (Allocation Failure) > 13G->13G(14G), 27.5541813 secs] > 2017-03-21T11:36:41.926-0400: 54918.488: [Full GC (Allocation Failure) > 13G->13G(14G), 33.7510103 secs] > 2017-03-21T11:37:16.132-0400: 54952.695: [Full GC (Allocation Failure) > 13G->13G(14G), 27.4856611 secs] > 2017-03-21T11:37:44.454-0400: 54981.017: [Full GC (Allocation Failure) > 13G->13G(14G), 28.1269335 secs] > 2017-03-21T11:38:12.774-0400: 55009.337: [Full GC (Allocation Failure) > 13G->13G(14G), 27.7830448 secs] > 2017-03-21T11:38:40.840-0400: 55037.402: [Full GC (Allocation Failure) > 13G->13G(14G), 27.3527326 secs] > 2017-03-21T11:39:08.610-0400: 55065.173: [Full GC (Allocation Failure) > 13G->13G(14G), 27.5828941 secs] > 2017-03-21T11:39:36.833-0400: 55093.396: [Full GC (Allocation Failure) > 13G->13G(14G), 27.9303030 secs] > 2017-03-21T11:40:05.265-0400: 55121.828: [Full GC (Allocation F
[jira] [Updated] (CASSANDRA-11881) OOM upgrading 2.2 to 3.6-tentative
[ https://issues.apache.org/jira/browse/CASSANDRA-11881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-11881: - Component/s: Testing > OOM upgrading 2.2 to 3.6-tentative > -- > > Key: CASSANDRA-11881 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11881 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Russ Hatch >Assignee: Russ Hatch >Priority: Major > > This has been repro'd a few times while running tests, such as > upgrade_tests/upgrade_through_versions_test.py:TestUpgrade_current_2_2_x_To_next_3_x.rolling_upgrade_test > {noformat} > java.lang.RuntimeException: java.util.concurrent.ExecutionException: > java.lang.OutOfMemoryError: Java heap space > at > org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119) > ~[main/:na] > at > org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108) > ~[main/:na] > at > org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92) > ~[main/:na] > at > org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321) > [main/:na] > at > org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581) > [main/:na] > at > org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710) > [main/:na] > Caused by: java.util.concurrent.ExecutionException: > java.lang.OutOfMemoryError: Java heap space > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > ~[na:1.8.0_92] > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > ~[na:1.8.0_92] > at > org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115) > ~[main/:na] > ... 5 common frames omitted > Caused by: java.lang.OutOfMemoryError: Java heap space > at > org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519) > ~[main/:na] > at > org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321) > ~[main/:na] > at > org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310) > ~[main/:na] > at > org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265) > ~[main/:na] > at > org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) > ~[main/:na] > at > org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245) > ~[main/:na] > at > org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:463) > ~[main/:na] > at > org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) > ~[main/:na] > at > org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150) > ~[main/:na] > at > org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72) > ~[main/:na] > at > org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226) > ~[main/:na] > at > org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182) > ~[main/:na] > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > ~[main/:na] > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82) > ~[main/:na] > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60) > ~[main/:na] > at > org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:805) > ~[main/:na] > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > ~[main/:na] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > ~[na:1.8.0_92] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > ~[na:1.8.0_92] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > ~[na:1.8.0_92] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > ~[na:1.8.0_92] > at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_92] > ERROR [CompactionExecutor:3] 2016-05-23 14:34:25,066 CassandraDaemon.java:213 > - Exception in thread Thread[CompactionExecutor:3,1,main] > java.lang.OutOfMemoryError: Java heap space > at > org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519) > ~[main/:na] > at > org.apache.cassandra.db.RowIndexEntry$Serializ
[jira] [Updated] (CASSANDRA-6486) Latency Measurement
[ https://issues.apache.org/jira/browse/CASSANDRA-6486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6486: Component/s: Metrics > Latency Measurement > --- > > Key: CASSANDRA-6486 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6486 > Project: Cassandra > Issue Type: Improvement > Components: Metrics >Reporter: Benedict >Priority: Minor > > Latency measurement in Cassandra is currently suboptimal. Exactly what the > latency measurements tell you isn't intuitively clear due to their > exponentially decaying, but amount to some view of the latency per > (unweighted) operation over the past, approximately, 10 minute period, with > greater weight given to more recent operations. This has some obvious flaws, > the most notable being that due to probabilistic sampling, large outlier > events (e.g. GC) can easily be lost over a multi-minute time horizon, and > even when caught are unlikely to appear even in the 99.9th percentile due to > accounting for a tiny fraction of events numerically. > I'm generally thinking about how we might improve on this, and want to dump > my ideas here for discussion. I think the following things should be targeted: > 1) Ability to see uniform latency measurements for different time horizons > stretching back from the present, e.g. last 1s, 1m, 1hr and 1day > 2) Ability to bound the error margin of statistics for all of these intervals > 3) Protect against losing outlier measurements > 4) Possibly offer the ability to weight statistics, so that longer latencies > are not underplayed even if they are counted > 5) Preferably non-blocking, memory efficient, and relatively garbage-free > (3) and (4) are the trickiest, as a theoretically sound and general approach > isn't immediately obvious. There are a number of possibilities that spring to > mind: > 1) ensure that we have enough sample points that we are probabilistically > guaranteed to not lose them, but over large time horizons this is problematic > due to memory constraints, and it doesn't address (4); > 2) count large events multiple times (or sub-slices of the events), based on > e.g. average op-rate. I am not a fan of this idea because it makes possibly > bad assumptions about behaviour and doesn't seem very theoretically sound; > 3) weight the probability of retaining an event by its length. the problem > with this approach is that it ties you into (4) without offering the current > view of statistics (i.e. unweighted operations), and it also doesn't lend > itself to efficient implementation > I'm currently leaning towards a fourth approach, which attempts to hybridise > uniform sampling and histogram behaviour, by separating the sample space into > ranges, each some multiple of the last (say 2x the size). Each range has a > uniform sample of events that occured in that range, plus a count of total > events. Ideally the size of the sample will be variable based on the number > of events occurring in any range, but that there will be a lower-bound > calculated to ensure we do not lose events. > This approach lends itself to all 5 goals above: > 1) by maintaining the same structure for each time horizon, and uniformly > sampling from all of the directly lower order time horizons to maintain it; > 2) by imposing minimum sample sizes for each range; > 3) ditto (2); > 4) by producing time/frequency-weighted statistics using the samples and > counts from each range; > 5) with thread-local array-based timers that are synchronised with the global > timer once every minimum period, by the owning thread > This also extends reasonably nicely the timers I have already written for > CASSANDRA-6199, so some of the work is already done. > Thoughts / discussion would be welcome, especially if you think I've missed > another obvious approach. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14702) Cassandra Write failed even when the required nodes to Ack(consistency) are up.
[ https://issues.apache.org/jira/browse/CASSANDRA-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14702: - Component/s: Coordination > Cassandra Write failed even when the required nodes to Ack(consistency) are > up. > --- > > Key: CASSANDRA-14702 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14702 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Rohit Singh >Priority: Blocker > > Hi, > We have following configuration in our project for cassandra. > Total nodes in Cluster-5 > Replication Factor- 3 > Consistency- LOCAL_QUORUM > We get the writetimeout exception from cassandra even when 2 nodes are up and > why does stack trace says that 3 replica were required when consistency is 2? > Below is the exception we got:- > com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout > during write query at consistency LOCAL_QUORUM (3 replica were required but > only 2 acknowledged the write) > at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:59) > at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:37) > at com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:289) > at com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:269) > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6917) enum data type
[ https://issues.apache.org/jira/browse/CASSANDRA-6917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6917: Component/s: CQL > enum data type > -- > > Key: CASSANDRA-6917 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6917 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Benedict >Priority: Minor > Labels: performance > > It seems like it would be useful to support an enum data type, that > automatically converts string data from the user into a fixed-width data type > with guaranteed uniqueness across the cluster. This data would be replicated > to all nodes for lookup, but ideally would use only the keyspace RF to > determine nodes for coordinating quorum writes/consistency. > This would not only permit improved local disk and inter-node network IO for > symbology information (e.g. stock tickers, ISINs, etc), but also potentially > for column identifiers also, which are currently stored as their full string > representation. > It should be possible then with later updates to propagate the enum map > (lazily) to clients through the native protocol, reducing network IO further. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14584) insert if not exists, with replication factor of 2 doesn't work
[ https://issues.apache.org/jira/browse/CASSANDRA-14584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14584: - Component/s: Coordination > insert if not exists, with replication factor of 2 doesn't work > --- > > Key: CASSANDRA-14584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14584 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: arik >Priority: Major > > Running with a single node cluster. > My keyspace has a replication factor of 2. > Insert if not exists doesn't work on that setup. > Produce the following error: > org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:720) > Caused by: com.datastax.driver.core.exceptions.NoHostAvailableException: All > host(s) tried for query failed (tried: cassandra-service/10.23.251.29:9042 > (com.datastax.driver.core.exceptions.UnavailableException: Not enough > replicas available for query at consistency QUORUM (2 required but only 1 > alive))) at > com.datastax.driver.core.RequestHandler.reportNoMoreHosts(RequestHandler.java:223) > at > com.datastax.driver.core.RequestHandler.access$1200(RequestHandler.java:41) > at > com.datastax.driver.core.RequestHandler$SpeculativeExecution.findNextHostAndQuery(RequestHandler.java:309) > at > com.datastax.driver.core.RequestHandler$SpeculativeExecution.retry(RequestHandler.java:477) > at > com.datastax.driver.core.RequestHandler$SpeculativeExecution.processRetryDecision(RequestHandler.java:455) > at > com.datastax.driver.core.RequestHandler$SpeculativeExecution.onSet(RequestHandler.java:686) > at > com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:1091) > at > com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:1008) > at > io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) > at > io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:287) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) > at > io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310) > at > io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) > at > io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86) > at > com.datastax.driver.core.InboundTrafficMeter.channelRead(InboundTrafficMeter.java:29) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) > at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1273) at > io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1084) at > io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489) > at > io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428) > at > io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) > at > io.netty.channel.AbstractChanne
[jira] [Updated] (CASSANDRA-2834) Avoid repair getting started twice at the same time for the same CF
[ https://issues.apache.org/jira/browse/CASSANDRA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-2834: Component/s: Repair > Avoid repair getting started twice at the same time for the same CF > --- > > Key: CASSANDRA-2834 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2834 > Project: Cassandra > Issue Type: Improvement > Components: Repair >Reporter: Terje Marthinussen >Priority: Minor > Labels: repair > > It may seem like it is possible to start repair twice at the same time on the > same CF? > Not 100% verified, but if this is indeed the case, we may want to consider > avoiding that including making nodetool repair abort and return and error if > repair is attempted on the same CF as one which already have repair running. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-3018) Make RPCTimeout be as close to "max time to respond to client" as possible
[ https://issues.apache.org/jira/browse/CASSANDRA-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-3018: Component/s: Configuration > Make RPCTimeout be as close to "max time to respond to client" as possible > -- > > Key: CASSANDRA-3018 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3018 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Sylvain Lebresne >Priority: Minor > > Quoting a comment of CASSANDRA-2494: > {quote} > rpctimeout is working exactly as intended, i.e., to prevent waiting > indefinitely for a node that died after we sent it a request. Treating it as > "max time to respond to client" has never really been correct. (E.g., in the > CL > ONE case we can already wait up to rpctimeout twice, one for the > original digest read set, and again for the data read after mismatch.) > {quote} > Let's make treating it as "max time to respond to client" more correct. It > should be too hard (we just need to grab the time at the start and make every > wait depend on how long we still have), and it will be more useful. It > probably cannot be perfect, but the goal is not to aim for sub-milisecond > precision, but to avoid the "waiting up twice the value 'asked' for". -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-967) Implement Read Repair on Range Queries
[ https://issues.apache.org/jira/browse/CASSANDRA-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-967: --- Component/s: Coordination > Implement Read Repair on Range Queries > -- > > Key: CASSANDRA-967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-967 > Project: Cassandra > Issue Type: Improvement > Components: Coordination >Affects Versions: 0.6.7 > Environment: Linux/Mac + Cassandra >Reporter: Vijay >Priority: Minor > Attachments: 0001-basic-read-repair-for-ranges-CASSANDRA-967.patch > > > Implement Read Repair on Range scans. > The idea is: To compare each rows in the list, if the responses mismatch then > send back a message resolution for that row alone to resolve the conflicts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-3670) provide "red flags" JMX instrumentation
[ https://issues.apache.org/jira/browse/CASSANDRA-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-3670: Component/s: Observability > provide "red flags" JMX instrumentation > --- > > Key: CASSANDRA-3670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3670 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Peter Schuller >Priority: Minor > > As discussed in CASSANDRA-3641, it would be nice to expose through JMX > certain information which is almost without exception indicative of something > being wrong with the node or cluster. > In the CASSANDRA-3641 case, it was the detection of corrupt counter shards. > Other examples include: > * Number of times the selection of files to compact was adjusted due to disk > space heuristics > * Number of times compaction has failed > * Any I/O error reading from or writing to disk (the work here is collecting, > not exposing, so maybe not in an initial version) > * Any data skipped due to checksum mismatches (when checksumming is being > used); e.g., "number of skips". > * Any arbitrary exception at least in certain code paths (compaction, scrub, > cleanup for starters) > Probably other things. > The motivation is that if we have clear and obvious indications that > something truly is wrong, it seems suboptimal to just leave that information > in the log somewhere, for someone to discover later when something else broke > as a result and a human investigates. You might argue that one should use > non-trivial log analysis to detect these things, but I highly doubt a lot of > people do this and it seems very wasteful to require that in comparison to > just providing the MBean. > It is important to note that the *lack* of a certain problem being advertised > in this MBean is not supposed to be indicative of a *lack* of a problem. > Rather, the point is that to the extent we can easily do so, it is nice to > have a clear method of communicating to monitoring systems where there *is* a > clear indication of something being wrong. > The main part of this ticket is not to cover everything under the sun, but > rather to reach agreement on adding an MBean where these types of indicators > can be collected. Individual counters can then be added over time as one > thinks of them. > I propose: > * Create an org.apache.cassandra.db.RedFlags MBean > * Populate with a few things to begin with. > I'll submit the patch if there is agreement. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-2443) Stream key/row caches during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-2443: Component/s: Streaming and Messaging > Stream key/row caches during bootstrap > -- > > Key: CASSANDRA-2443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2443 > Project: Cassandra > Issue Type: Improvement > Components: Streaming and Messaging >Reporter: Chris Goffinet >Priority: Minor > Labels: ponies > > When adding new nodes to an existing cluster, if we streamed key and row > caches over right before node came into cluster, we could minimize the impact > of a cold node, and reduce the time for the node to get 'warmed' up. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-3858) expose "propagation delay" metric in JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-3858: Component/s: Metrics > expose "propagation delay" metric in JMX > > > Key: CASSANDRA-3858 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3858 > Project: Cassandra > Issue Type: Improvement > Components: Metrics >Reporter: Peter Schuller >Priority: Minor > > My idea is to augment the gossip protocol to contain timestamps. We wouldn't > use the timestamps for anything "important", but we could use them to allow > each node to expose a number which is the number of milliseconds (or seconds) > "old" information is about nodes that are "the oldest" and also alive. > When nodes go down you'd see spikes, but for most cases where nodes live, > this information should give you a pretty good idea of how fast gossip > information is propagating through the cluster, assuming you keep your clocks > in synch. > It should be a good thing to have graphed, and to have alerts on. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-3830) gossip-to-seeds is not obviously independent of failure detection algorithm
[ https://issues.apache.org/jira/browse/CASSANDRA-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-3830: Component/s: (was: Streaming and Messaging) Distributed Metadata > gossip-to-seeds is not obviously independent of failure detection algorithm > > > Key: CASSANDRA-3830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3830 > Project: Cassandra > Issue Type: Task > Components: Distributed Metadata >Reporter: Peter Schuller >Assignee: Peter Schuller >Priority: Minor > > The failure detector, ignoring all the theory, boils down to an > extremely simple algorithm. The FD keeps track of a sliding window (of > 1000 currently) intervals of heartbeat for a given host. Meaning, we > have a track record of the last 1000 times we saw an updated heartbeat > for a host. > At any given moment, a host has a score which is simply the time since > the last heartbeat, over the *mean* interval in the sliding > window. For historical reasons a simple scaling factor is applied to > this prior to checking the phi conviction threshold. > (CASSANDRA-2597 has details, but thanks to Paul's work there it's now > trivial to understand what it does based on gut feeling) > So in effect, a host is considered down if we haven't heard from it in > some time which is significantly longer than the "average" time we > expect to hear from it. > This seems reasonable, but it does assume that under normal conditions > the average time between heartbeats does not change for reasons other > than those that would be plausible reasons to think a node is > unhealthy. > This assumption *could* be violated by the gossip-to-seed > feature. There is an argument to avoid gossip-to-seed for other > reasons (see CASSANDRA-3829), but this is a concrete case in which the > gossip-to-seed could cause a negative side-effect of the general kind > mentioned in CASSANDRA-3829 (see notes at end about not case w/o seeds > not being continuously tested). Normally, due to gossip to seed, > everyone essentially sees latest information within very few hart > beats (assuming only 2-3 seeds). But should all seeds be down, > suddenly we flip a switch and start relying on generalized propagation > in the gossip system, rather than the seed special case. > The potential problem I forese here is that if the average propagation > time suddenly spikes when all seeds become available, it could cause > bogus flapping of nodes into down state. > In order to test this, I deployeda ~ 180 node cluster with a version > that logs heartbet information on each interpret(), similar to: > INFO [GossipTasks:1] 2012-02-01 23:29:58,746 FailureDetector.java (line 187) > ep /XXX.XXX.XXX.XXX is at phi 0.0019521638443084342, last interval 7.0, mean > is 1557.27778 > It turns out that, at least at 180 nodes, with 4 seed nodes, whether > or not seeds are running *does not* seem to matter significantly. In > both cases, the mean interval is around 1500 milliseconds. > I don't feel I have a good grasp of whether this is incidental or > guaranteed, and it would be good to at least empirically test > propagation time w/o seeds at differnet cluster sizes; it's supposed > to be un-affected by cluster size ({{RING_DELAY}} is static for this > reason, is my understanding). Would be nice to see this be the case. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-3810) reconsider rack awareness
[ https://issues.apache.org/jira/browse/CASSANDRA-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-3810: Component/s: Core > reconsider rack awareness > - > > Key: CASSANDRA-3810 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3810 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Peter Schuller >Assignee: Peter Schuller >Priority: Minor > > We believed we wanted to be rack aware because we want to ensure that loosing > a rack only affects a single replica of any given row key. > When using rack awareness, the first problem you encounter immediately if you > aren't careful is that you induce hotspots as a result of rack aware replica > selection. Using the format {{rackname-nodename}}, consider a part of the > ring that looks like this: > {code} > ... > r1-n1 > r1-n2 > r1-n3 > r2-n1 > r3-n1 > r4-n1 > ... > {code} > Due to the rack awareness, {{r2-n1}} will be the second replica for all data > whose primary replica is on {{r1-n1}}, {{r1-n2}} and {{r1-n3}} since they > would all be forced to skip over any identical racks. > The way we end up allocating nodes in a cluster is to satisfy this criteria: > * Any node in rack {{r}} in a cluster of a replication factor of {{rf}}, must > not have another node in {{r}} within {{rf-1}} steps in the ring in either > direction. > Any violation of this criteria implies the induction of hotspots due to rack > awareness. > The realization however, that I had a few days ago, is that *the > rackawareness is not actually changing replica placement* when using this > ring topology. In other words, *the way you have to use* rack awareness is to > construct the ring such that *the rack awareness is a NOOP*. > So, questions: > * Is there any non-hotspot inducing use-case where rack awareness can be used > ("used" in the sense that it actually changes the placement relative to > non-awareness) effectively without satisfying the criteria above? > * Is it misleading and counter-productive to teach people (via documentation > for example) to rely on rack awareness in their rings instead of just giving > them the rule above for ring topology? > * Would it be a better service to the user to provide an easy way to *ensure* > that the ring topology adheres to this criteria (such as refusing to > bootstrap a new node if rack awareness is requested, and taking it into > consideration on automatic token selection (does anyone use that?)), than to > "silently" generate hotspots by altering the replication strategy? (The > "silence" problem is magnified by the fact that {{nodetool ring}} doesn't > reflect this; so the user must take into account both the RF *and* the racks > when interpreting {{nodetool ring}} output.) > FWIW, internally we just go with the criteria outlined above, and we have a > separate tool which will print the *actual* ownership percentage of a node in > the ring (based on the thrift {{describe_ring}} call). Any ring that has node > selections that causes a violation of the criteria is effectively a > bug/mis-configured ring, so only in the event of mistakes are we "using" the > rack awareness (using the definition of "use" above). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-4245) Provide a locale/collation-aware text comparator
[ https://issues.apache.org/jira/browse/CASSANDRA-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-4245: Component/s: Core > Provide a locale/collation-aware text comparator > > > Key: CASSANDRA-4245 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4245 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Ertio Lew >Priority: Minor > > It is a common use case to use a bunch of entity names as column names & then > use the row as a search index, using search by range. For such use cases & > others, it is useful to have a UTF8 comparator that provides case insensitive > ordering of columns. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-4967) config options have different bounds when set via different methods
[ https://issues.apache.org/jira/browse/CASSANDRA-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-4967: Component/s: Configuration > config options have different bounds when set via different methods > --- > > Key: CASSANDRA-4967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4967 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Affects Versions: 1.2.0 beta 2 >Reporter: Robert Coli >Priority: Minor > Labels: lhf > > (similar to some of the work done in > https://issues.apache.org/jira/browse/CASSANDRA-4479 > ) > If one sets a value in cassandra.yaml, that value might be subject to bounds > checking there. However if one sets that same value via JMX, it doesn't get > set via a bounds-checking code path. > "./src/java/org/apache/cassandra/config/DatabaseDescriptor.java" (JMX set) > {noformat} > public static void setPhiConvictThreshold(double phiConvictThreshold) > { > conf.phi_convict_threshold = phiConvictThreshold; > } > {noformat} > Versus.. > ./src/java/org/apache/cassandra/config/DatabaseDescriptor.java > (cassandra.yaml) > {noformat} > static void loadYaml() > ... > /* phi convict threshold for FailureDetector */ > if (conf.phi_convict_threshold < 5 || conf.phi_convict_threshold > > 16) > { > throw new ConfigurationException("phi_convict_threshold must > be between 5 and 16"); > } > {noformat} > This seems to create a confusing situation where the range of potential > values for a given configuration option is different when set by different > methods. > It's difficult to imagine a circumstance where you want bounds checking to > keep your node from starting if you set that value in cassandra.yaml, but > also want to allow circumvention of that bounds checking if you set via JMX. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-4758) Allow throttling bulk load separately from streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-4758: Component/s: Streaming and Messaging > Allow throttling bulk load separately from streaming > > > Key: CASSANDRA-4758 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4758 > Project: Cassandra > Issue Type: Improvement > Components: Streaming and Messaging >Reporter: Nick Bailey >Priority: Major > Labels: ponies > > Currently when you call the bulkload jmx call, the only way to achieve > throttling is by tuning the streaming throttle in general, which affects all > streaming operations. > It would be nice to be able to throttle bulk loading separately. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-4756) Bulk loading snapshots creates RF^2 copies of the data
[ https://issues.apache.org/jira/browse/CASSANDRA-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-4756: Component/s: Core > Bulk loading snapshots creates RF^2 copies of the data > -- > > Key: CASSANDRA-4756 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4756 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.2.0 beta 1 >Reporter: Nick Bailey >Priority: Major > > Since a cluster snapshot will contain rf copies of each piece of data, > bulkloading all of those snapshots will create rf^2 copies of each piece of > data. > Not sure what the solution here is. Ideally we would merge the RF copies of > the data before sending to the cluster. This would solve any inconsistencies > that existed when the snapshot was taken. > A more naive approach of only loading one of the RF copies and assuming there > are no inconsistencies might be an easier goal for the near term though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5048) Allow caching on column families to be configured on differently per data center
[ https://issues.apache.org/jira/browse/CASSANDRA-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5048: Component/s: Configuration > Allow caching on column families to be configured on differently per data > center > > > Key: CASSANDRA-5048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5048 > Project: Cassandra > Issue Type: Wish > Components: Configuration >Affects Versions: 1.2.0 rc1 >Reporter: Delaney Manders >Priority: Minor > > When using one data center for hadoop/analytics, one as a canonical store and > for serving high volume writes, and possibly even one for low-latency reads, > the tuning requirements are dramatically different on the same column family. > I suspect being able to configure caching on just one datacentre would really > make a difference. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5849) Create Trigger tests in dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5849: Component/s: Testing > Create Trigger tests in dtests > -- > > Key: CASSANDRA-5849 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5849 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Ryan McGuire >Assignee: Ryan McGuire >Priority: Major > > Write some distributed tests using triggers. > See CASSANDRA-5574 for examples. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5741) Provide a way to disable automatic index rebuilds during bulk loading
[ https://issues.apache.org/jira/browse/CASSANDRA-5741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5741: Component/s: Secondary Indexes > Provide a way to disable automatic index rebuilds during bulk loading > - > > Key: CASSANDRA-5741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5741 > Project: Cassandra > Issue Type: Improvement > Components: Secondary Indexes >Affects Versions: 1.2.6 >Reporter: Jim Zamata >Priority: Major > > When using the BulkLoadOutputFormat the actual streaming of the SSTables into > Cassandra is fast, but the index rebuilds can take several minutes. Cassandra > does not send the response until after all of the rebuilds for a streaming > session complete. This causes the tasks to appear to hang at 100%, since the > record writer streams the files in its close method. If the rebuilding > process takes too long, the tasks can actually time out. > Many SQL databases provide bulk insert utilities that disable index updates > to allow large amounts of data to be added quickly. This functionality would > serve a similar purpose. > An alternative might be an option that would allow the session to return once > the SSTables had been successfully imported without waiting for the index > builds to complete. However, I have noticed heavy CPU loads during the index > rebuilds, so bulkload performance might be better if this step could be > deferred until after all of the data is loaded. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5047) Allow bloom_filter_fp_chance to be configured differently per data center
[ https://issues.apache.org/jira/browse/CASSANDRA-5047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5047: Component/s: Configuration > Allow bloom_filter_fp_chance to be configured differently per data center > - > > Key: CASSANDRA-5047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5047 > Project: Cassandra > Issue Type: Wish > Components: Configuration >Affects Versions: 1.2.0 rc1 >Reporter: Delaney Manders >Priority: Minor > > When using one data center for hadoop/analytics exclusively, one for serving > high volume writes, and possibly even one for reads, the tuning requirements > are dramatically different on the same column family. > The biggest heap cost on a large dataset is the bloom_filter. It would be > great to be able to disable/tune it as a per-datacentre setting. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5853) Write dtests that use json2sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5853: Component/s: Testing > Write dtests that use json2sstable > -- > > Key: CASSANDRA-5853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5853 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Ryan McGuire >Assignee: Kishan Karunaratne >Priority: Major > > Currently in dtest we test sstableloader for import/export. With the bug > found in CASSANDRA-5852 there appears to be a need to test the json tools as > well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5092) make hinted handoff per CF configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5092: Component/s: Hints > make hinted handoff per CF configurable > --- > > Key: CASSANDRA-5092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5092 > Project: Cassandra > Issue Type: Improvement > Components: Hints >Reporter: Matthew F. Dennis >Priority: Minor > > hinted handoff should be configurable per CF (or at least per KS) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7693) Reminder: clean up Javadoc errors/warnings
[ https://issues.apache.org/jira/browse/CASSANDRA-7693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7693: Component/s: Documentation and Website > Reminder: clean up Javadoc errors/warnings > -- > > Key: CASSANDRA-7693 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7693 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Robert Stupp >Priority: Trivial > > Current C* build (trunk) reports > 100 errors + > 100 warnings (when building > with Java8). > Trivial but long ("keyboard monkey") task: Clean up the errors. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5861) Test decomission LEFT state serialization
[ https://issues.apache.org/jira/browse/CASSANDRA-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5861: Component/s: Testing > Test decomission LEFT state serialization > - > > Key: CASSANDRA-5861 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5861 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Ryan McGuire >Assignee: Ryan McGuire >Priority: Major > > Make sure things like CASSANDRA-5857 don't crop up again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5313) provide a cardinality function for collection types ( CQL3 )
[ https://issues.apache.org/jira/browse/CASSANDRA-5313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5313: Component/s: CQL > provide a cardinality function for collection types ( CQL3 ) > > > Key: CASSANDRA-5313 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5313 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Ahmet AKYOL >Priority: Major > Labels: cql > > Currently , cql3 doesn't provide a cardinality function for collection types. > It'll be great to have one: > {code} > select content, cardinality(like_set),cardinality(dislike_set) from comments > where id=?; > {code} > or size as keyword > {code} > select content, size(like_set),size(dislike_set) from comments where id=?; > {code} > Something similar in SQL is [cardinality of nested > tables|http://www.techonthenet.com/oracle/functions/cardinality.php] . -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5972) Reduce the amount of data to be transferred during repair
[ https://issues.apache.org/jira/browse/CASSANDRA-5972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5972: Component/s: Repair > Reduce the amount of data to be transferred during repair > - > > Key: CASSANDRA-5972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5972 > Project: Cassandra > Issue Type: Improvement > Components: Repair >Reporter: Jacek Lewandowski >Priority: Minor > > Currently, when a validator finds a token range different in n replicas, data > streams are initiated simultaneously between each possible pair of these n > nodes, in both directions. It yields n*(n-1) data stream in total. > It can be done in a sequence - Replica[1] -> R[2], R[2] -> R[3], ... , R[n-1] > -> R[n]. After this process, the data in R[n] are up to date. Then, we > continue: R[n] -> R[1], R[1] -> R[2], ... , R[n-2] -> R[n-1]. The active > repair is done after 2*(n-1) data transfers performed sequentially in 2*(n-1) > steps. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5962) Support trigger parametrization
[ https://issues.apache.org/jira/browse/CASSANDRA-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5962: Component/s: CQL > Support trigger parametrization > --- > > Key: CASSANDRA-5962 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5962 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Aleksey Yeschenko >Priority: Minor > Labels: cql3, triggers > > We don't have a convenient way to parametrize triggers, which limits their > reusability and usability in general. For any configuration you have to rely > on external config files. > We already have [trigger_options map] column in > system.schema_triggers, all we need is to add the right syntax to CQL3 > (CREATE TRIGGER foo ON bar USING class WITH options = {..}) and modify > ITrigger to support it. > Setting fixver to 2.1, but might move to 2.0.x later. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6091) Better Vnode support in hadoop/pig
[ https://issues.apache.org/jira/browse/CASSANDRA-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6091: Component/s: (was: Core) Libraries > Better Vnode support in hadoop/pig > -- > > Key: CASSANDRA-6091 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6091 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Alex Liu >Assignee: mck >Priority: Minor > Attachments: cassandra-2.0-6091.txt, cassandra-2.1-6091.txt, > trunk-6091.txt > > > CASSANDRA-6084 shows there are some issues during running hadoop/pig job if > vnodes are enable. Also the hadoop performance of vnode enabled nodes are > bad for there are so many splits. > The idea is to combine vnode splits into a big sudo splits so it work like > vnode is disable for hadoop/pig job -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5091) Provide a way to sort read results on the coordinator node
[ https://issues.apache.org/jira/browse/CASSANDRA-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5091: Component/s: Coordination > Provide a way to sort read results on the coordinator node > -- > > Key: CASSANDRA-5091 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5091 > Project: Cassandra > Issue Type: Wish > Components: Coordination >Reporter: Sergio Bossa >Priority: Major > Labels: cql > > While Cassandra provides a way to scatter/gather queries with secondary > indexes, as well as custom secondary indexes implementations, there is > currently no way to sort gathered results on the coordinator node, which > would be very useful (actually, essential) if the index implementation > provides results in sorted order. > So, what I'm proposing here is a way to provide (custom) sort > implementations, which may either be as easy as just adding one more > interface and a bunch of method calls, or get a bit more complex by providing > an ORDER BY clause in CQL. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6061) Rewrite TokenMetadata
[ https://issues.apache.org/jira/browse/CASSANDRA-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6061: Component/s: Core > Rewrite TokenMetadata > - > > Key: CASSANDRA-6061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6061 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Jonathan Ellis >Priority: Minor > > Feels like this "mostly works" but is generally fragile (see: shuffle). > Would be good to get a fresh perspective on it and see if we can do better. > Bonus would be, ability to bootstrap multiple nodes w/o Two Minute Rule. > Probably would involve using LWT on pending ranges state. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6091) Better Vnode support in hadoop/pig
[ https://issues.apache.org/jira/browse/CASSANDRA-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6091: Component/s: Core > Better Vnode support in hadoop/pig > -- > > Key: CASSANDRA-6091 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6091 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Alex Liu >Assignee: mck >Priority: Minor > Attachments: cassandra-2.0-6091.txt, cassandra-2.1-6091.txt, > trunk-6091.txt > > > CASSANDRA-6084 shows there are some issues during running hadoop/pig job if > vnodes are enable. Also the hadoop performance of vnode enabled nodes are > bad for there are so many splits. > The idea is to combine vnode splits into a big sudo splits so it work like > vnode is disable for hadoop/pig job -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-8036) Add dtest for ipv6 functionality
[ https://issues.apache.org/jira/browse/CASSANDRA-8036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-8036: Component/s: Testing > Add dtest for ipv6 functionality > > > Key: CASSANDRA-8036 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8036 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Philip Thompson >Priority: Major > > Cassandra can run with ipv6 addresses, and cqlsh should be able to connect > via ipv6. We need a dtest to verify this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-8117) Checksum all communication between Cassandra nodes
[ https://issues.apache.org/jira/browse/CASSANDRA-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-8117: Component/s: Streaming and Messaging > Checksum all communication between Cassandra nodes > -- > > Key: CASSANDRA-8117 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8117 > Project: Cassandra > Issue Type: Improvement > Components: Streaming and Messaging >Reporter: sankalp kohli >Priority: Major > > We have seen corruption in Gossip due to corruption happening in the n/w card > between main memory which is ECC protected and TCP checksum. Same corruption > can happen to other data flowing b/w machines. We should add checksum to all > communication b/w machines in the application. > A different JIRA could be to add checksums from the client driver for writes > and back to the driver for reads. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5912) Optimize listing partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5912: Component/s: CQL > Optimize listing partition keys > --- > > Key: CASSANDRA-5912 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5912 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Sylvain Lebresne >Assignee: Suresh >Priority: Minor > > That's a small followup to optimize the DISTINCT support added by > CASSANDRA-4536 if we feel like it's worth it. > Quoting the initial ticket: it should be possible to optimize that further if > we consider it worth it by adding a 1 bit per key info in the sstable index > saying 'is there at least one live column for that key in that sstable' (we > could even add that bit-per-key without augmenting the on-disk index size if > we want to by using the first bit of the key position (since we use it as a > signed long and thus the first bit is unused)). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5888) Need a way to start or bootstrap a node regardless of its current state
[ https://issues.apache.org/jira/browse/CASSANDRA-5888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-5888: Component/s: Lifecycle > Need a way to start or bootstrap a node regardless of its current state > --- > > Key: CASSANDRA-5888 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5888 > Project: Cassandra > Issue Type: Improvement > Components: Lifecycle >Reporter: Oleg Kibirev >Priority: Major > > Currently, there is no straightforward way to start a cassandra node on a > given host without knowing: > 1. Weather the node's initial_token has been successfully registered through > gossip > 2. If the node has successfully finished bootstrapping > 3. Weather data directory has been purged by, say, replacing a dead disk > Specifically the following cases are problematic: > 1. If a data directory is purged and the node is restarted with the same host > IP and initial token, the node will successfully start but will not > bootstrap, creating a silent consistency loss. > 2. If -Dcassandra.replace_token is given, the node will bootstrap again, even > if its successfully bootstrapped already with the same token. > The information on the correct thing to do can only come from gossip and > system keyspace. Its very difficult to infer correct start arguments from a > process external to cassandra and have it work 100% of the time on large > scale. What if a node already gossiped its token but has not successfully > finished bootstrapping - how do I know to drop replace_token and will it > still re-bootstrap? > Cassandra daemon should always bootstrap on start if it hasn't yet finished > bootstrapping successfully. -Dcassandra.replace_token (or host replacement > equivalent with nodes) should just ALLOW replacing a token of a down node, > but not force an unnecessary bootstrap or fail if the token is not present. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-8224) Checksum Gossip state
[ https://issues.apache.org/jira/browse/CASSANDRA-8224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-8224: Component/s: Distributed Metadata > Checksum Gossip state > - > > Key: CASSANDRA-8224 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8224 > Project: Cassandra > Issue Type: Improvement > Components: Distributed Metadata >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Minor > Attachments: incomplete_trunk_8224.diff > > > We have seen that a single machine with bad memory can corrupt the gossip of > other nodes and cause entire cluster to be affected. If we store and pass the > checksum of the entire state, we can detect corruption. If a bad machine > tries to bump the generation number or other things, it will be detected and > ignored. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6408) Efficient multi-partition mutations
[ https://issues.apache.org/jira/browse/CASSANDRA-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6408: Component/s: Core > Efficient multi-partition mutations > --- > > Key: CASSANDRA-6408 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6408 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Rick Branson >Priority: Major > > At the SF Summit this year, Sylvain suggested that C* drops a very large > amount of write throughput on the floor for multi-partition mutations because > they are broken into RowMutations and executed individually. Stress tests > that I've run show 10X the throughput for 1-row x 1000-col writes versus > 1000-row x 1-col writes. We have a core high-write-skew use case which > involves fan-out-on-write against hundreds or up to thousands of keys at a > time currently implemented in Redis as it doesn't seem to suffer from the > issue. Would love to be able to move this to C* at some point. > This is likely a pretty large undertaking as it would require touching a > large portion of the write path, but I figure I'd put it here for comment > and/or debate at this point. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7764) RFC: Range movements will "wake up" previously invisible data
[ https://issues.apache.org/jira/browse/CASSANDRA-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7764: Component/s: Core > RFC: Range movements will "wake up" previously invisible data > - > > Key: CASSANDRA-7764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7764 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Rick Branson >Priority: Major > Labels: triaged > > Presumably this has been going on as long as Cassandra has existed, but > wanted to capture it here since it came up in an IRC discussion. This issue > will probably show up on any cluster eventually. > Scenario: > 1) Start with a 3-node cluster, RF=1 > 2) A 4th node is added to the cluster > 3) Data is deleted on ranges belonging to 4th node > 4) Wait for GC to clean up some tombstones on 4th node > 4) 4th node removed from cluster > 5) Deleted data will reappear since it was dormant on the original 3 nodes > This could definitely happen in many other situations where dormant data > could exist such as inconsistencies that aren't resolved before range > movement, but the case above seemed the most reasonable to propose as a > real-world problem. > The cleanup operation can be used to get rid of the dormant data, but from my > experience people don't run cleanup unless they're low on disk. It's > definitely not a best practice for data integrity. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7592) Ownership changes can violate consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-7592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7592: Component/s: Core > Ownership changes can violate consistency > - > > Key: CASSANDRA-7592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7592 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Richard Low >Priority: Major > > CASSANDRA-2434 goes a long way to avoiding consistency violations when > growing a cluster. However, there is still a window when consistency can be > violated when switching ownership of a range. > Suppose you have replication factor 3 and all reads and writes at quorum. The > first part of the ring looks like this: > Z: 0 > A: 100 > B: 200 > C: 300 > Choose two random coordinators, C1 and C2. Then you bootstrap node X at token > 50. > Consider the token range 0-50. Before bootstrap, this is stored on A, B, C. > During bootstrap, writes go to X, A, B, C (and must succeed on 3) and reads > choose two from A, B, C. After bootstrap, the range is on X, A, B. > When the bootstrap completes, suppose C1 processes the ownership change at t1 > and C2 at t4. Then the following can give an inconsistency: > t1: C1 switches ownership. > t2: C1 performs write, so sends write to X, A, B. A is busy and drops the > write, but it succeeds because X and B return. > t3: C2 performs a read. It hasn’t done the switch and chooses A and C. > Neither got the write at t2 so null is returned. > t4: C2 switches ownership. > This could be solved by continuing writes to the old replica for some time > (maybe ring delay) after the ownership changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7822) Confusing timeout on CAS contention
[ https://issues.apache.org/jira/browse/CASSANDRA-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7822: Component/s: Coordination > Confusing timeout on CAS contention > --- > > Key: CASSANDRA-7822 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7822 > Project: Cassandra > Issue Type: Improvement > Components: Coordination >Reporter: sankalp kohli >Priority: Minor > Labels: LWT > > If we have contention in CAS and we hit the cas contention timeout, we throw > an exception. In this timeout exception, we pass that 0 replicas responded. > This is very confusing to someone looking at the client logs. I think we > might need to throw a separate exception for contention or may be add a flag > in the timeout exception. > We have seen many people confused by this so I think we should fix it. > This is how we throw it on contention. > throw new WriteTimeoutException(WriteType.CAS, consistencyForPaxos, 0, > consistencyForPaxos.blockFor(Keyspace.open(keyspaceName))); -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6193) Move throughput-heavy activities (repair/compaction) into separate process
[ https://issues.apache.org/jira/browse/CASSANDRA-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6193: Component/s: Core > Move throughput-heavy activities (repair/compaction) into separate process > -- > > Key: CASSANDRA-6193 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6193 > Project: Cassandra > Issue Type: Wish > Components: Core >Reporter: André Cruz >Priority: Minor > Labels: ponies > > Repairs and compactions are activities that I've seen cause Full GCs. It is > difficult to optimize the GC for pauseless behaviour when the jvm is > performing such different functions as serving client requests and processing > large data files. > Wouldn't it be possible to separate repairs/compactions into another process > where Full GCs would not be a problem? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6288) Make compaction a priority queue
[ https://issues.apache.org/jira/browse/CASSANDRA-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6288: Component/s: Compaction > Make compaction a priority queue > > > Key: CASSANDRA-6288 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6288 > Project: Cassandra > Issue Type: Wish > Components: Compaction >Reporter: Jonathan Ellis >Assignee: Jeff Jirsa >Priority: Minor > Labels: compaction > > We should prioritize compacting CFs by how many reads/s its preferred > candidate would save, divided by the number of bytes in the sstables. > (Note that STCS currently divides by number of keys; ISTM that bytes will > work better since that does not penalize narrow rows.) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6177) remove all sleeps in the dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6177: Component/s: Testing > remove all sleeps in the dtests > --- > > Key: CASSANDRA-6177 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6177 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Brandon Williams >Priority: Major > > The dtests use a ton of sleep calls for various things, most of which is > guessing if Cassandra has finished doing something or not. Guessing is > problematic and shouldn't be necessary -- a prime example of this is creating > a ks or cf. When done over cql, we sleep and hope it's done propagating, but > when done over thrift we actually check for schema agreement. We should be > able to eliminate the sleeps and reliably detect when it's time for the next > step programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6412) Custom creation and merge functions for user-defined column types
[ https://issues.apache.org/jira/browse/CASSANDRA-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6412: Component/s: Core > Custom creation and merge functions for user-defined column types > - > > Key: CASSANDRA-6412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6412 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Nicolas Favre-Felix >Priority: Major > > This is a proposal for a new feature, mapping custom types to Cassandra > columns. > These types would provide a creation function and a merge function, to be > implemented in Java by the user. > This feature relates to the concept of CRDTs; the proposal is to replicate > "operations" on these types during write, to apply these operations > internally during merge (Column.reconcile), and to also merge their values on > read. > The following operations are made possible without reading back any data: > * MIN or MAX(value) for a column > * First value for a column > * Count Distinct > * HyperLogLog > * Count-Min > And any composition of these too, e.g. a Candlestick type includes first, > last, min, and max. > The merge operations exposed by these types need to be commutative; this is > the case for many functions used in analytics. > This feature is incomplete without some integration with CASSANDRA-4775 > (Counters 2.0) which provides a Read-Modify-Write implementation for > distributed counters. Integrating custom creation and merge functions with > new counters would let users implement complex CRDTs in Cassandra, including: > * Averages & related (sum of squares, standard deviation) > * Graphs > * Sets > * Custom registers (even with vector clocks) > I have a working prototype with implementations for min, max, and Candlestick > at https://github.com/acunu/cassandra/tree/crdts - I'd appreciate any > feedback on the design and interfaces. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6752) Streaming should pause when receiving host is overwhelmed
[ https://issues.apache.org/jira/browse/CASSANDRA-6752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6752: Component/s: Streaming and Messaging > Streaming should pause when receiving host is overwhelmed > - > > Key: CASSANDRA-6752 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6752 > Project: Cassandra > Issue Type: Improvement > Components: Streaming and Messaging >Reporter: sankalp kohli >Priority: Minor > Labels: ponies, streaming > > During repair, sometimes repair bring in lot of data and the disk gets full > on the node. A cassandra node should better protect itself by monitoring its > disk space and pausing incoming streams. > Outgoing throttle can help but this automatic check will make operations > easier. > Lot of improvements have been done on repair specially incremental repairs > which makes this less of a problem but I think this could still be useful and > will avoid operator shooting itself in the foot. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6340) Provide a mechanism for retrieving all replicas
[ https://issues.apache.org/jira/browse/CASSANDRA-6340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6340: Component/s: Coordination > Provide a mechanism for retrieving all replicas > --- > > Key: CASSANDRA-6340 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6340 > Project: Cassandra > Issue Type: New Feature > Components: Coordination > Environment: Production >Reporter: Ahmed Bashir >Priority: Minor > Labels: ponies > > In order to facilitate problem diagnosis, there should exist some mechanism > to retrieve all copies of specific columns -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6394) Accessing and setting expiration time of a column (instead of TTL)
[ https://issues.apache.org/jira/browse/CASSANDRA-6394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6394: Component/s: CQL > Accessing and setting expiration time of a column (instead of TTL) > -- > > Key: CASSANDRA-6394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6394 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Patrick Varilly >Priority: Minor > Labels: cql3, features, timestamp, ttl > Original Estimate: 24h > Remaining Estimate: 24h > > When selecting and inserting/updating columns, one can get/set the TIMESTAMP > / WRITETIME and TTL. However, this is not enough information to recreate the > column's expiration time (clock sync and network latency between the client > and server get in the way). This makes updating columns with a set TTL > fragile: there is no way to make the new value of a column *expire* at the > same time as the old value. > Ideally, you'd be able to say something like: > SELECT x, y EXPIRATIONTIME( y ) FROM my_cf > and > UPDATE my_cf USING EXPIRATIONTIME sameAsFromSelect SET y = newy WHERE x = > oldx. > The use case I'm facing is that I write an entire row with a given TTL, and > might later want to update a few of its columns. Currently, that makes the > updated columns live longer than the non-updated columns. Of course, you can > come up with a good approximation for the appropriate TTL in the update to > make the updated columns expire at *around* the same time, but not at > *exactly* the same time. Since Cassandra stores an expiration time > internally, making the expiration *exactly* simultaneous should be possible, > but CQL3 does not expose this ability. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6422) Add ability to control HintedHandoff threads per datacenter
[ https://issues.apache.org/jira/browse/CASSANDRA-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6422: Component/s: Hints > Add ability to control HintedHandoff threads per datacenter > --- > > Key: CASSANDRA-6422 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6422 > Project: Cassandra > Issue Type: Improvement > Components: Hints >Reporter: Adam Hattrell >Priority: Minor > > I have a user that would like to be able to define how many threads and the > throughput limits for each DC. > To quote: > Having different thread counts for local DC vs remote as well as separate > bandwidth limits certainly makes sense. Expanding on this, I could foresee > that if there are more than two DCs that being able to configure each one > independently would be hugely beneficial, as latency/available bandwidth to > each DC may differ, as well as the number of nodes per DC. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6444) Have a nodetool command which emits true data size
[ https://issues.apache.org/jira/browse/CASSANDRA-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6444: Component/s: Tools > Have a nodetool command which emits true data size > -- > > Key: CASSANDRA-6444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6444 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: sankalp kohli >Priority: Minor > > Sometimes we have an unbalanced clusters and it is difficult to know whether > some nodes are taking more space because updated have not yet been compacted > away or it is due to distribution of data. > So we need to know the true fully compacted data size. > We can do this with validation compaction and summing up the size of all > rows. > We should also emit such a sum during repair when the Merkle tree is being > generated. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6588) Add a 'NO EMPTY RESULTS' filter to SELECT
[ https://issues.apache.org/jira/browse/CASSANDRA-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6588: Component/s: CQL > Add a 'NO EMPTY RESULTS' filter to SELECT > - > > Key: CASSANDRA-6588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6588 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Sylvain Lebresne >Priority: Minor > > It is the semantic of CQL that a (CQL) row exists as long as it has one > non-null column (including the PK columns, which, given that no PK columns > can be null, means that it's enough to have the PK set for a row to exist). > This does means that the result to > {noformat} > CREATE TABLE test (k int PRIMARY KEY, v1 int, v2 int); > INSERT INTO test(k, v1) VALUES (0, 4); > SELECT v2 FROM test; > {noformat} > must be (and is) > {noformat} > v2 > -- > null > {noformat} > That fact does mean however that when we only select a few columns of a row, > we still need to find out rows that exist but have no values for the selected > columns. Long story short, given how the storage engine works, this means we > need to query full (CQL) rows even when only some of the columns are selected > because that's the only way to distinguish between "the row exists but have > no value for the selected columns" and "the row doesn't exist". I'll note in > particular that, due to CASSANDRA-5762, we can't unfortunately rely on the > row marker to optimize that out. > Now, when you selects only a subsets of the columns of a row, there is many > cases where you don't care about rows that exists but have no value for the > columns you requested and are happy to filter those out. So, for those cases, > we could provided a new SELECT filter. Outside the potential convenience (not > having to filter empty results client side), one interesting part is that > when this filter is provided, we could optimize a bit by only querying the > columns selected, since we wouldn't need to return rows that exists but have > no values for the selected columns. > For the exact syntax, there is probably a bunch of options. For instance: > * {{SELECT NON EMPTY(v2, v3) FROM test}}: the vague rational for putting it > in the SELECT part is that such filter is kind of in the spirit to DISTINCT. > Possibly a bit ugly outside of that. > * {{SELECT v2, v3 FROM test NO EMPTY RESULTS}} or {{SELECT v2, v3 FROM test > NO EMPTY ROWS}} or {{SELECT v2, v3 FROM test NO EMPTY}}: the last one is > shorter but maybe a bit less explicit. As for {{RESULTS}} versus {{ROWS}}, > the only small object to {{NO EMPTY ROWS}} could be that it might suggest it > is filtering non existing rows (I mean, the fact we never ever return non > existing rows should hint that it's not what it does but well...) while we're > just filtering empty "resultSet rows". > Of course, if there is a pre-existing SQL syntax for that, it's even better, > though a very quick search didn't turn anything. Other suggestions welcome > too. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6672) Support for Microsecond Resolution Time UUIDs in CQL3
[ https://issues.apache.org/jira/browse/CASSANDRA-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6672: Component/s: CQL > Support for Microsecond Resolution Time UUIDs in CQL3 > - > > Key: CASSANDRA-6672 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6672 > Project: Cassandra > Issue Type: Wish > Components: CQL >Reporter: Drew Kutcharian >Priority: Major > > Currently CQL3 supports time uuid based functions (now, unixtimestampof, > dateof, ...) that deal with millisecond resolution time uuids. I think it > will be a good idea to have the microsecond resolution version of those > functions. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6727) Specify particular endpoints to be used during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6727: Component/s: Streaming and Messaging > Specify particular endpoints to be used during bootstrap > - > > Key: CASSANDRA-6727 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6727 > Project: Cassandra > Issue Type: Improvement > Components: Streaming and Messaging >Reporter: sankalp kohli >Priority: Minor > > Sometimes there is a need to bootstrap a node from a set of endpoints which > you want to specify. We should allow specifying set of endpoints while > starting to be used and override the endpoints which get picked up due to > snitch. > Here is a example in which it will be useful. > A cluster is being upgraded and before upgradestable could be run on all > replicas, we want to replace a node. > With this feature, we can specify a node on which we have already run > upgradestable and bootstrap a node. > This feature is less useful with v-nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6768) Refresh permissions cache in ClientState periodically to avoid cache miss stampede effect
[ https://issues.apache.org/jira/browse/CASSANDRA-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6768: Component/s: Auth > Refresh permissions cache in ClientState periodically to avoid cache miss > stampede effect > - > > Key: CASSANDRA-6768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6768 > Project: Cassandra > Issue Type: Improvement > Components: Auth >Reporter: Michał Michalski >Assignee: Michał Michalski >Priority: Major > Labels: authentication > > h2. Background > We want to password-protect Cassandra by using the built-in > PasswordAuthenticator and PasswordAuthorizer. In general we are happy with > this solution, but after reviewing the code we're a bit afraid of default > permissionsCache behaviour in org.apache.cassandra.service.ClientState. > h2. Problem > From what I understand, at the moment cache expires every N seconds (2 by > default) and it gets repopulated when permissionsCache.get() is being > called. However, as we're talking about at least a few hundreds requests to > Cassandra per second, we're afraid of the "stampede" effect once the cache > expires and a number of queries will "trigger" its reload simultaneously > during the short period of time when it will be empty. > h2. Proposed Solutions > Therefore, instead of the current solution, we'd prefer this cache to be > reloaded "in background" every N seconds, so it's only a single request every > N seconds, rather than tens (hundreds?) of them just after the cache expires > during the period when it's empty. > In other words, we're thinking about two solutions (updated after comments > from [~jjordan] and [~iamaleksey]): > h3. Make the ClientState's permissionsCache configurable. > Let's define additional configurable variable called refreshPeriod and make > it 0 by default (0 means no refresh - nothing changes in current code). If > it's > 0, add the refreshAfterWrite to the existing code. > This way we keep the defaults "safe", but add possibility to "tune" the cache > when someone needs it. Any cons? > h3. Make Authorizer responsible for its own cache > As I said, I believe that Authorizer should be responsible for defining its > cache, so I'd prefer to add a getPermissionsCache method to IAuthorizer and > get rid of the cache creating code in ClientState. Of course it's a bigger > change, it breaks the existing interface, but from my point of view it's the > better choice. > Of course there's no problem to combine these two options and make the > per-Authorizer cache configurable. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6760) Nodetool command to disable reads
[ https://issues.apache.org/jira/browse/CASSANDRA-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6760: Component/s: Configuration > Nodetool command to disable reads > - > > Key: CASSANDRA-6760 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6760 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: sankalp kohli >Priority: Minor > > There is no way to stop a node from accepting reads and still be part of the > ring. > This will be helpful in case node does not bootstrap properly and we need to > run node tool rebuild to fetch the data. > The node can use gossip to propagate this fact to other nodes so that they > don't forward reads to it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6903) Allow a token scan to filter on partition key columns
[ https://issues.apache.org/jira/browse/CASSANDRA-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6903: Component/s: Core > Allow a token scan to filter on partition key columns > - > > Key: CASSANDRA-6903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6903 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Andy Neilson >Priority: Major > > When extracting data for analysis (e.g., in Hadoop) using a token scan, > allowing filtering on column that is part of the partition key allow for more > efficient processing. For example, assume that we have the following schema > (from the example defined > [here|http://planetcassandra.org/blog/post/getting-started-with-time-series-data-modeling/]): > {noformat} > CREATE TABLE temperature_by_day ( >weatherstation_id text, >date text, >event_time timestamp, >temperature text, >PRIMARY KEY ((weatherstation_id,date),event_time) > ); > {noformat} > Assume that I am primarily interested in doing analysis of more recent data, > so I can use a SELECT like the following to extract the data I am interested > in: > {noformat} > SELECT * > FROM temperature_by_day > WHERE token(weatherstation_id,date) > ? AND token(weatherstation_id,date) <= ? > AND event_time >= ? > LIMIT 5000 > ALLOW FILTERING; > {noformat} > The filtering is potentially expensive since it touches a lot of columns. > Since the {{date}} column that is used to fragment wide rows is related to > the {{event_time}}, I could apply a (redundant) filter to {{date}}, as in: > {noformat} > SELECT * > FROM temperature_by_day > WHERE token(weatherstation_id,date) > ? AND token(weatherstation_id,date) <= ? > AND event_time >= ? > AND date >= ? > LIMIT 5000 > ALLOW FILTERING; > {noformat} > ...but currently I can't add the filter on the {{date}} column because it is > part of the partition key. However, because this query is doing a token scan, > there really is no problem in filtering on the partition key. The predicate > on {{date}} can be evaluated directly on the row index without looking at the > values in columns at all. The effect is to efficiently filter out a large > swath of rows, and not forcing the scan to filter on rows that couldn't > possibly contain those dates. > There are probably lots of ways to optimize predicates on partition key > columns. For example, if the {{date}} column was made the first column in the > partition key, evaluating a range could be done without scanning the entire > row index. > In this case, if we have a year of data, but are only interested in > extracting the last day, so the overhead of filtering is reduced by a factor > of 365. > What I am looking for is: > * If the SELECT is a token scan, allow filtering on partition key columns. > * Predicates on partition key columns are evaluated on for the row as a > whole, before filtering on clustering columns. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6897) Add checksum to the Summary File and Bloom Filter file of SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6897: Component/s: Local Write-Read Paths > Add checksum to the Summary File and Bloom Filter file of SSTables > -- > > Key: CASSANDRA-6897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6897 > Project: Cassandra > Issue Type: Improvement > Components: Local Write-Read Paths >Reporter: Adam Hattrell >Priority: Major > > Could we add a checksum to the Summary file and filter file of the SSTable. > Since reads the whole bloom filter before actually reading data, it seems > like it would make sense to checksum the bloom filter to make sure there is > no corruption there. Same is true with the summary file. The core of our > question is, can you add checksumming to all elements of the SSTable so if we > read anything corrupt we immediately see a failure? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7022) Consider an option to reduce tracing cost by writing only to sessions table (not events)
[ https://issues.apache.org/jira/browse/CASSANDRA-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7022: Component/s: Observability > Consider an option to reduce tracing cost by writing only to sessions table > (not events) > > > Key: CASSANDRA-7022 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7022 > Project: Cassandra > Issue Type: Improvement > Components: Observability > Environment: C* 2.0.6 running on Ubuntu 12.04 >Reporter: Bill Joyce >Priority: Minor > > With MySQL and SQL Server, I can profile all queries in high traffic > production environments. I'm assuming the bulk of the C* tracing cost comes > in writing to the system_traces.events table, so it would be great to have an > option to write just the system_traces.session info if that allows me to run > 'nodetool settraceprobability' with a higher probability (ideally a > probability of 1). This along with CASSANDRA-7021 would go a long way in > giving us performance analysis closer to what can be done with more mature > back ends. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6990) Log ClosedChannelException at DEBUG at shutdown in CompressedRandomAccessReader
[ https://issues.apache.org/jira/browse/CASSANDRA-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6990: Component/s: Observability > Log ClosedChannelException at DEBUG at shutdown in > CompressedRandomAccessReader > --- > > Key: CASSANDRA-6990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6990 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Jeremy Hanna >Priority: Minor > > Related to CASSANDRA-5368, there is another spot where we are not catching > ClosedChannelException messages on shutdown. > The trace is: > {quote} > ERROR [Deserialize > SSTableReader(path='/data10/cassandra/ks1/cf1/ks1-cf1-ic-246-Data.db')] > 2014-04-06 04:01:00,753 CassandraDaemon.java (line 191) Exception in thread > Thread[Deserialize > SSTableReader(path='/data10/cassandra/ks1/cf1/ks1-cf1-ic-246-Data.db'),1,main] > FSReadError in /data10/cassandra/ks1/cf1/ks1-cf1-ic-246-Data.db > at > org.apache.cassandra.io.compress.CompressedRandomAccessReader.reBuffer(CompressedRandomAccessReader.java:93) > at > org.apache.cassandra.io.compress.CompressedThrottledReader.reBuffer(CompressedThrottledReader.java:45) > at > org.apache.cassandra.io.util.RandomAccessReader.read(RandomAccessReader.java:327) > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:756) > at java.io.RandomAccessFile.readLong(RandomAccessFile.java:792) > at > org.apache.cassandra.utils.BytesReadTracker.readLong(BytesReadTracker.java:114) > at > org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:107) > at > org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:92) > at > org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumnsFromSSTable(ColumnFamilySerializer.java:149) > at > org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:234) > at > org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer$1.runMayThrow(ParallelCompactionIterable.java:291) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.nio.channels.ClosedChannelException > at sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:88) > at sun.nio.ch.FileChannelImpl.position(FileChannelImpl.java:243) > at > org.apache.cassandra.io.compress.CompressedRandomAccessReader.checksum(CompressedRandomAccessReader.java:140) > at > org.apache.cassandra.io.compress.CompressedRandomAccessReader.decompressChunk(CompressedRandomAccessReader.java:127) > at > org.apache.cassandra.io.compress.CompressedRandomAccessReader.reBuffer(CompressedRandomAccessReader.java:85) > ... 12 more > {quote} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6794) Optimise slab allocator to enable higher number of column families
[ https://issues.apache.org/jira/browse/CASSANDRA-6794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6794: Component/s: Core > Optimise slab allocator to enable higher number of column families > -- > > Key: CASSANDRA-6794 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6794 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jeremy Hanna >Priority: Minor > > Currently the slab allocator allocates 1MB per column family. This has been > very beneficial for gc efficiency. However, it makes it more difficult to > have large numbers of column families. > It would be preferable to have a more intelligent way to allocate slabs so > that there is more flexibility between slab allocator and non-slab allocator > behaviour. > A simple first step is to ramp up size of slabs from small (say 8KB) when > empty, to 1MB after a few slabs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7061) High accuracy, low overhead local read/write tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7061: Component/s: Observability > High accuracy, low overhead local read/write tracing > > > Key: CASSANDRA-7061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7061 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Benedict >Priority: Major > > External profilers are pretty inadequate for getting accurate information at > the granularity we're working at: tracing is too high overhead, so measures > something completely different, and sampling suffers from bias of attribution > due to the way the stack traces are retrieved. Hyperthreading can make this > even worse. > I propose to introduce an extremely low overhead tracing feature that must be > enabled with a system property that will trace operations within the node > only, so that we can perform various accurate low level analyses of > performance. This information will include threading info, so that we can > trace hand off delays and actual active time spent processing an operation. > With the property disabled there will be no increased burden of tracing, > however I hope to keep the total trace burden to less than one microsecond, > and any single trace command to a few tens of nanos. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6917) enum data type
[ https://issues.apache.org/jira/browse/CASSANDRA-6917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-6917: Issue Type: New Feature (was: Improvement) > enum data type > -- > > Key: CASSANDRA-6917 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6917 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Benedict >Priority: Minor > Labels: performance > > It seems like it would be useful to support an enum data type, that > automatically converts string data from the user into a fixed-width data type > with guaranteed uniqueness across the cluster. This data would be replicated > to all nodes for lookup, but ideally would use only the keyspace RF to > determine nodes for coordinating quorum writes/consistency. > This would not only permit improved local disk and inter-node network IO for > symbology information (e.g. stock tickers, ISINs, etc), but also potentially > for column identifiers also, which are currently stored as their full string > representation. > It should be possible then with later updates to propagate the enum map > (lazily) to clients through the native protocol, reducing network IO further. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-8612) Read metrics should be updated on all types of reads
[ https://issues.apache.org/jira/browse/CASSANDRA-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-8612: Component/s: Metrics > Read metrics should be updated on all types of reads > > > Key: CASSANDRA-8612 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8612 > Project: Cassandra > Issue Type: Improvement > Components: Metrics >Reporter: Chris Lohfink >Priority: Minor > Labels: lhf, metrics > > Metrics like "sstables per read" are not updated on a range slice. Although > separating things out for each type of read could make sense like we do for > latencies, only exposing the metrics for one type can be a little confusing > when people do a query and see nothing increases. I think its sufficient to > use the same metrics for all reads. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-8470) Commit Log / Memtable Flush Correctness Stress Test
[ https://issues.apache.org/jira/browse/CASSANDRA-8470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-8470: Component/s: Testing > Commit Log / Memtable Flush Correctness Stress Test > --- > > Key: CASSANDRA-8470 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8470 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Benedict >Priority: Major > > CASSANDRA-8383 should have been detected with automated testing. We should > introduce a stress test designed to expose any bugs in the core data paths. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-8433) Add jmx and nodetool controls to reset lifetime metrics to zero
[ https://issues.apache.org/jira/browse/CASSANDRA-8433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-8433: Component/s: Metrics > Add jmx and nodetool controls to reset lifetime metrics to zero > --- > > Key: CASSANDRA-8433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8433 > Project: Cassandra > Issue Type: Improvement > Components: Metrics >Reporter: Donald Smith >Priority: Minor > > Often I change some parameter in cassandra, in the OS, or in an external > component and want to see the effect on cassandra performance. Because some > the jmx metrics are for the lifetime of the process, it's hard to see the > effect of changes. It's inconvenient to restart all the nodes. And if you > restart only some nodes (as I often do) then only those metrics reset to zero. > The jmx interface should provide a way to reset all lifetime metrics to zero. > And *nodetool* should invoke that to allow resetting metrics from the > command line. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-8342) Remove historical guidance for concurrent reader and writer tunings.
[ https://issues.apache.org/jira/browse/CASSANDRA-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-8342: Component/s: Documentation and Website > Remove historical guidance for concurrent reader and writer tunings. > > > Key: CASSANDRA-8342 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8342 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Matt Stump >Priority: Major > > The cassandra.yaml and documentation provide guidance on tuning concurrent > readers or concurrent writers to system resources (cores, spindles). Testing > performed by both myself and customers demonstrates no benefit for thread > pool sizes above 64 in size, and for thread pools greater than 128 in size a > decrease in throughput. This is due to thread scheduling and synchronization > bottlenecks within Cassandra. > Additionally, for lower end systems reducing these thread pools provides very > little benefit because the bottleneck is typically moved to either IO or CPU. > I propose that we set the default value to 64 (current default is 32), and > remove all guidance/recommendations regarding tuning. > This recommendation may change in 3.0, but that would require further > experimentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7180) Investigate mutation testing for unit tests
[ https://issues.apache.org/jira/browse/CASSANDRA-7180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7180: Component/s: Testing > Investigate mutation testing for unit tests > --- > > Key: CASSANDRA-7180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7180 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Russ Hatch >Assignee: Russ Hatch >Priority: Major > > We might get some useful information from mutation testing tools, possibly > PIT (http://pitest.org/). The basic idea is to seed faults in the code and > check to see if the unit tests are able to catch them. If we can get this up > and running, perhaps it could be run periodically on cassci.datastax.com. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7433) Improve information for Unknown table/cf error message
[ https://issues.apache.org/jira/browse/CASSANDRA-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7433: Component/s: Observability > Improve information for Unknown table/cf error message > -- > > Key: CASSANDRA-7433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7433 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Adam Hattrell >Priority: Minor > > Could we add some further details to the following types of error: > {code:none} > ERROR [Thread-11235] 2014-06-20 11:08:20,278 StorageService.java (line 2436) > Repair session failed: > java.lang.IllegalArgumentException: Unknown table/cf pair > (counterpartyrisk.deals20140602HPCE_OFFICIAL) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:165) > at > org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2293) > > at > org.apache.cassandra.service.StorageService.forceTableRepair(StorageService.java:2485) > > at > org.apache.cassandra.service.StorageService$5.runMayThrow(StorageService.java:2432) > > at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.lang.Thread.run(Thread.java:744) > {code} > Specifically that this is expected if you have recently dropped the > associated column family. I don't think this should be dropped to a WARN as > if you haven't changed your schema recently then this probably indicates a > significant problem. In the majority of cases though - it can probably be > safely ignored. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7065) Add some extra metadata in leveled manifest to be able to reduce the amount of sstables searched on read path
[ https://issues.apache.org/jira/browse/CASSANDRA-7065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7065: Component/s: Local Write-Read Paths > Add some extra metadata in leveled manifest to be able to reduce the amount > of sstables searched on read path > - > > Key: CASSANDRA-7065 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7065 > Project: Cassandra > Issue Type: Improvement > Components: Local Write-Read Paths >Reporter: Marcus Eriksson >Priority: Major > Labels: lcs > > Based on this; > http://rocksdb.org/blog/431/indexing-sst-files-for-better-lookup-performance/ > By keeping pointers from the sstables in lower to higher levels we could > reduce the number of candidates in higher levels, ie, instead of searching > all 1000 L3 sstables, we use the information from the L2 search to include > less L3 sstables. > First we need to figure out if this can beat our IntervalTree approach (and > if the win is worth it). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7184) improvement of SizeTieredCompaction
[ https://issues.apache.org/jira/browse/CASSANDRA-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7184: Component/s: Compaction > improvement of SizeTieredCompaction > - > > Key: CASSANDRA-7184 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7184 > Project: Cassandra > Issue Type: Improvement > Components: Compaction >Reporter: Jianwei Zhang >Assignee: Jianwei Zhang >Priority: Minor > Labels: compaction > Original Estimate: 48h > Remaining Estimate: 48h > > 1, In our usage scenario, there is no duplicated insert and no delete . The > data increased all the time, and some big sstables are generated (100GB for > example). we don't want these sstables to participate in the > SizeTieredCompaction any more. so we add a max threshold which is set to > 100GB . Sstables larger than the threshold will not be compacted. Should this > strategy be added to the trunk ? > 2, In our usage scenario, maybe hundreds of sstable need to be compacted in > a Major Compaction. The total size would be larger to 5TB. So during the > compaction, when the size writed reach to a configed threshhold(200GB for > example), it switch to write a new sstable. In this way, we avoid to generate > too huge sstables. Too huge sstable have some bad infuence: > (1) It will be larger than the capacity of a disk; > (2) If the sstable is corrupt, lots of objects will be influenced . > Should this strategy be added to the trunk ? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7426) ALTER SYSTEM / nodetool enhancements
[ https://issues.apache.org/jira/browse/CASSANDRA-7426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7426: Component/s: Distributed Metadata Configuration > ALTER SYSTEM / nodetool enhancements > > > Key: CASSANDRA-7426 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7426 > Project: Cassandra > Issue Type: Improvement > Components: Configuration, Distributed Metadata >Reporter: Robert Stupp >Priority: Major > Labels: cql > > CASSANDRA-7370 mentions the idea to enhance nodetool to do something like > {{nodetool> set config foo='bar'}}. This could also be done via a "special" > CQL {{ALTER SYSTEM SET foo='bar';}}. > In general this ticket is just meant not keep in mind that there should be > some option to change configuration using a generic approach. Either > implementation (nodetool via JMX or CQL statement) should internally end at > the same code. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7213) look into failure testing using libfiu
[ https://issues.apache.org/jira/browse/CASSANDRA-7213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7213: Component/s: Testing > look into failure testing using libfiu > -- > > Key: CASSANDRA-7213 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7213 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Russ Hatch >Assignee: Russ Hatch >Priority: Major > > libfiu might be a useful library for simulating system failures. We should > look into using this within cassandra-dtest or independently. Ideally we'll > want some control over how specific test nodes should behave ("node A should > fail as if problem X has occurred"), so we'll want to look into somehow > conditionally failing calls for specific nodes and perhaps intermittent > probabilistic failures too. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7296) Add CL.COORDINATOR_ONLY
[ https://issues.apache.org/jira/browse/CASSANDRA-7296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7296: Component/s: Coordination > Add CL.COORDINATOR_ONLY > --- > > Key: CASSANDRA-7296 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7296 > Project: Cassandra > Issue Type: Improvement > Components: Coordination >Reporter: Tupshin Harper >Priority: Major > > For reasons such as CASSANDRA-6340 and similar, it would be nice to have a > read that never gets distributed, and only works if the coordinator you are > talking to is an owner of the row. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7597) Remove static initializer in DatabaseDescriptor
[ https://issues.apache.org/jira/browse/CASSANDRA-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7597: Component/s: Lifecycle > Remove static initializer in DatabaseDescriptor > --- > > Key: CASSANDRA-7597 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7597 > Project: Cassandra > Issue Type: Improvement > Components: Lifecycle > Environment: Cassandra 2.0.9 (earlier version should be affected as > well) >Reporter: Pavel Sakun >Priority: Major > Attachments: 7597.txt > > > As discussed below, it's difficult to properly react on invalid configuration > values in a client tool that uses cassandra code (here: an sstable loader). > Reason is that the static initializer in DatabaseDescriptor calls System.exit > in case of configuration failures. > Recommend to implement some "loadAndApplyConfig" method on DatabaseDescriptor > and remove the static initializer and let the calling code react accordingly > (print error, exit VM). > All direct and indirect uses of DatabaseDescriptor must be catched to solve > this ticket - so this is not a 2.1 ticket. > -- > Old Description: > We're using SSTableSimpleUnsortedWriter API to generate SSTable to be loaded > into cassandra. In case of any issue with config DatabaseDescriptor calls > System.exit() which is apparently not the thing you expect while using API. > Test case is simple: > System.setProperty( "cassandra.config", "" ); > new YamlConfigurationLoader().loadConfig(); > Thread.sleep( 5000 ); > System.out.println("We're still alive"); // this will never be called -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7439) There are a number of places where Gossiper.instance.getEndpointStateForEndpoint is not checked for null
[ https://issues.apache.org/jira/browse/CASSANDRA-7439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7439: Component/s: Distributed Metadata > There are a number of places where > Gossiper.instance.getEndpointStateForEndpoint is not checked for null > > > Key: CASSANDRA-7439 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7439 > Project: Cassandra > Issue Type: Task > Components: Distributed Metadata >Reporter: Mike Adamson >Priority: Minor > > In most places the getEndpointStateForEndpoint method is null checked but in > a number of places it isn't. > Without testing each individual call point it is difficult to tell from the > context whether the state will be null or not. > In this case wouldn't it make sense to null every call to this method to > avoid race conditions and NPEs -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7540) When indicating corruption, specify the sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-7540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7540: Component/s: Observability > When indicating corruption, specify the sstable > --- > > Key: CASSANDRA-7540 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7540 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Jeremy Hanna >Priority: Major > > In the 2.0 line, there was #6285 where hsha introduced some corruption. If > you're hit by this, you get the DecoratedKey message that indicates that one > of the sstables getting compacted had the error in it. It would be much > nicer to know which sstable had that problem. Otherwise, you're left having > to ss2j each of the sstables involved in the compaction until you've found > it/them. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7548) Disk I/O priority control for Compaction and Flusher
[ https://issues.apache.org/jira/browse/CASSANDRA-7548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7548: Component/s: Core > Disk I/O priority control for Compaction and Flusher > > > Key: CASSANDRA-7548 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7548 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Hanson >Priority: Major > > Disk I/O priority: Memtables Flusher shall have higher priority than > Compaction. > This is to avoid DB Insert/Update hung (spikes) during SSTables Compaction. > The Compaction shall be able to detect the in-progress of Memtables flushing, > and slow down itself for disk I/O. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7589) Option to disable min timestamp check for TTL compaction enhancements
[ https://issues.apache.org/jira/browse/CASSANDRA-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7589: Component/s: Compaction > Option to disable min timestamp check for TTL compaction enhancements > - > > Key: CASSANDRA-7589 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7589 > Project: Cassandra > Issue Type: Improvement > Components: Compaction >Reporter: Matt Stump >Priority: Minor > > As part of CASSANDRA-5228 we added an enhancement to unlink SSTables for TTL > use cases if certain checks are met. One of those checks is that for an > SSTable to be deleted the maximum timestamp must not be less than the minimum > timestamp for all other SSTables. This makes sense for use cases where GC > grace is >= the TTL, or use case where deletes are performed by the > application. > For use cases where GC grace is less than the TTL, and where deletes are only > performed via TTL then these checks result in SSTables that could be safely > deleted sticking around for some time. In practice the TTL related > enhancements kick in very infrequently and most SSTables go through the > normal compaction process. > What I propose is a CF level setting that disables the check, so that an > SSTable can be unlinked once time() >= max TTL. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7530) Repair should be allowed in mixed version clusters
[ https://issues.apache.org/jira/browse/CASSANDRA-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7530: Component/s: Repair > Repair should be allowed in mixed version clusters > -- > > Key: CASSANDRA-7530 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7530 > Project: Cassandra > Issue Type: Improvement > Components: Repair >Reporter: Jeremiah Jordan >Priority: Major > Labels: ponies > > As we try to improve the ops experience for large clusters (or cautious > people), we need to make it so repair works across major version upgrades. > Currently you have to be able to upgrade all of your nodes and then run a > full repair, within the gc_grace window. > The recent ability to stream old sstables makes this a little better, as you > don't have to also run upgradesstables first. > It would be really good if we could let people pause their upgrade of 1000 > nodes to run some repairs. Or to upgrade one DC and test the new major > version for a while (while still running repairs). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7720) Add a more consistent snapshot mechanism
[ https://issues.apache.org/jira/browse/CASSANDRA-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7720: Component/s: Tools > Add a more consistent snapshot mechanism > > > Key: CASSANDRA-7720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7720 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Mike Schrag >Priority: Major > > We’ve hit an interesting issue with snapshotting, which makes sense in > hindsight, but presents an interesting challenge for consistent restores: > * initiate snapshot > * snapshotting flushes table A and takes the snapshot > * insert into table A > * insert into table B > * snapshotting flushes table B and takes the snapshot > * snapshot finishes > So what happens here is that we end up having a B, but NOT having an A, even > though B was chronologically inserted after A. > It makes sense when I think about what snapshot is doing, but I wonder if > snapshots actually should get a little fancier to behave a little more like > what I think most people would expect. What I think should happen is > something along the lines of the following: > For each node: > * pass a client timestamp in the snapshot call corresponding to "now" > * snapshot the tables using the existing procedure > * walk backwards through the linked snapshot sstables in that snapshot > * if the earliest update in that sstable is after the client's timestamp, > delete the sstable in the snapshot > * if the earliest update in the sstable is before the client's timestamp, > then look at the last update. Walk backwards through that sstable. > * if any updates fall after the timestamp, make a copy of that sstable in > the snapshot folder only up to the point of the timestamp and then delete the > original sstable in the snapshot (we need to copy because we're likely > holding a shared hard linked sstable) > I think this would guarantee that you have a chronologically consistent view > of your snapshot across all machines and columnfamilies within a given > snapshot. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7723) sstable2json (and possibly other command-line tools) hang if no write permission to the commitlogs
[ https://issues.apache.org/jira/browse/CASSANDRA-7723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7723: Component/s: Tools > sstable2json (and possibly other command-line tools) hang if no write > permission to the commitlogs > -- > > Key: CASSANDRA-7723 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7723 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: J.B. Langston >Priority: Minor > > sstable2json (and potentially other command-line tools that call > DatabaseDescriptor.loadSchemas) will hang if the user running them doesn't > have write permission on the commit logs. loadSchemas calls > Schema.updateVersion, which causes a mutation to the system tables, then it > just spins forever trying to acquire a commit log segment. See this thread > dump: https://gist.github.com/markcurtis1970/837e770d1cad5200943c. The tools > should recognize this and present an understandable error message. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7880) Create a new system table "schema_change_history"
[ https://issues.apache.org/jira/browse/CASSANDRA-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7880: Component/s: Distributed Metadata > Create a new system table "schema_change_history" > - > > Key: CASSANDRA-7880 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7880 > Project: Cassandra > Issue Type: New Feature > Components: Distributed Metadata >Reporter: Michaël Figuière >Priority: Minor > > The current way Cassandra handle schema modification can lead to some schema > disagreements as DDL statements execution doesn't come with any absolute > guarantee. I understand that entirely seamless schema updates in such a > distributed system will be challenging to reach and probably not a high > priority for now. > That being said these disagreements can sometime lead to challenging > situation for scripts or tools that need things to be in order to move on. To > clarify the situation, help the user to figure out what's going on, as well > as to properly log these sensitive operations, it would be interesting to add > a {{schema_change_history}} table in the {{system}} keyspace. > I would expect it to be local to a node and to contain the following > information: > * DDL statement that has been executed > * User login used for the operation > * IP of the client that originated the request > * Date/Time of the change > * Schema version before the change > * Schema version after the change > Under normal conditions, Cassandra shouldn't handle a massive amount of DDL > statements so this table should grow at a descent pace. Nevertheless to bound > its growth we can consider adding a TTL. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7746) fix upgrade_through_versions local mode for rolling upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7746: Component/s: Testing > fix upgrade_through_versions local mode for rolling upgrades > > > Key: CASSANDRA-7746 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7746 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Russ Hatch >Priority: Minor > > Upgrade tests now have a local mode for easier debugging with local code > modifications (instead of fetching remote versions). This works by locally > changing branches and building cassandra as needed. > There's a potential problem for rolling upgrades because the code will be > updated while some of the nodes are still using the last version. I'm not > certain if this really affects much in practice but should be relatively > straightforward to fix. > Instead of switching branches, the tests will need to check out the target > branch/tag to another location on the filesystem. When upgrading, another > version will be checked out to another location on the filesystem, etc. To > keep this (hopefully) platform agnostic we should be able to use the python > tempfile module, and git can probably be used to check out a single branch as > described here: > http://stackoverflow.com/questions/1778088/how-to-clone-a-single-branch-in-git -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7958) Create jenkins targets to run CQLTester unit tests with prepared statements and without
[ https://issues.apache.org/jira/browse/CASSANDRA-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7958: Component/s: Testing Build > Create jenkins targets to run CQLTester unit tests with prepared statements > and without > --- > > Key: CASSANDRA-7958 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7958 > Project: Cassandra > Issue Type: Test > Components: Build, Testing >Reporter: Ryan McGuire >Assignee: Michael Shuler >Priority: Major > > The CQL tests within the unit test code has the ability to run with prepared > statements, or without, using the cassandra.test.use_prepared flag. We should > create two jenkins targets on CassCI to run it both ways. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7907) Determine how many network threads we need for native transport
[ https://issues.apache.org/jira/browse/CASSANDRA-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7907: Component/s: CQL > Determine how many network threads we need for native transport > --- > > Key: CASSANDRA-7907 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7907 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Benedict >Priority: Minor > > With the introduction of CASSANDRA-4718, it is highly likely we can cope with > just _one_ network IO thread. We could even try pinning it to a single > (optionally configurable) core, and (also optionally) pin all other threads > to a different core, so that we can guarantee extremely prompt execution (and > if pinned to the correct core the OS uses for managing the network, improve > throughput further). > Testing this out will be challenging, as we need to simulate clients from > lots of IPs. However, it is quite likely this would reduce the percentage of > time spent in kernel networking calls, and the amount of context switching. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7999) Inconsistent logging in CassandraDaemon
[ https://issues.apache.org/jira/browse/CASSANDRA-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7999: Component/s: Testing > Inconsistent logging in CassandraDaemon > --- > > Key: CASSANDRA-7999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7999 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Shaun Kalley >Priority: Minor > > Both fatal and non-fatal errors are being logged at error level which creates > a problem for monitoring. CassandraDaemon.setup() logs an error-level > message if a directory does not exist but is still able to continue if the > directory can be created, and CassandraDaemon.activate() logs an error-level > message if the MBean cannot be registered but still allows the server to > start. I'd like to see the logging levels for these issues downgraded to > warning, or the levels for the fatal errors upgraded to fatal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7955) Range movements can violate consistency if RING_DELAY <= write_request_timeout_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7955: Component/s: Coordination > Range movements can violate consistency if RING_DELAY <= > write_request_timeout_in_ms > > > Key: CASSANDRA-7955 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7955 > Project: Cassandra > Issue Type: Improvement > Components: Coordination >Reporter: Benedict >Priority: Minor > > Cassandra should probably refuse to start if RING_DELAY is too close to (or > below) write_request_timeout_ms, because we depend on this for > correctness/consistency during range movements > We should probably also consider throwing a WriteTimeoutException _even if we > don't get interrupted by the timeout, since there are reasons due to > scheduling or system overload this could not happen (though it is unlikely to > be significant enough to have an impact, it's better safe than sorry) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7900) Snapshot tests are not platform neutral
[ https://issues.apache.org/jira/browse/CASSANDRA-7900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-7900: Component/s: Testing > Snapshot tests are not platform neutral > --- > > Key: CASSANDRA-7900 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7900 > Project: Cassandra > Issue Type: Test > Components: Testing > Environment: Windows >Reporter: Philip Thompson >Priority: Major > Labels: Windows > > The various snapshot and commit log archiving tests in snapshot_test.py are > failing on Windows platforms. This appears to be the fault of test behavior > due to extensive operations in the file system that fail to consider the test > may be running on Windows. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org