[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>
[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,
[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,
[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
[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
>
[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 >
[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
