date:20140731

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 40d7bdf80 - 63407db7e


Avoid NPE when listing saved caches directory

Patch by marcuse; reviewed by yukim for CASSANDRA-7632


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1a0aaf04
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1a0aaf04
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1a0aaf04

Branch: refs/heads/cassandra-2.1
Commit: 1a0aaf04986155eae45b2685d234b928866b681c
Parents: 892bf55
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jul 31 07:53:33 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jul 31 07:53:33 2014 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java | 23 
 2 files changed, 15 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1a0aaf04/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a6fc837..1fcb556 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -22,6 +22,7 @@
  * Fix error when doing reversed queries with static columns (CASSANDRA-7490)
  * Backport CASSANDRA-6747 (CASSANDRA-7560)
  * Track max/min timestamps for range tombstones (CASSANDRA-7647)
+ * Fix NPE when listing saved caches dir (CASSANDRA-7632)
 Merged from 1.2:
  * Set correct stream ID on responses when non-Exception Throwables
are thrown while handling native protocol messages (CASSANDRA-7470)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1a0aaf04/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--
diff --git a/src/java/org/apache/cassandra/cache/AutoSavingCache.java 
b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
index 6554eb3..64234e2 100644
--- a/src/java/org/apache/cassandra/cache/AutoSavingCache.java
+++ b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
@@ -261,19 +261,24 @@ public class AutoSavingCacheK extends CacheKey, V 
extends InstrumentingCacheK
 {
 File savedCachesDir = new 
File(DatabaseDescriptor.getSavedCachesLocation());
 assert savedCachesDir.exists()  savedCachesDir.isDirectory();
-
-for (File file : savedCachesDir.listFiles())
+File[] files = savedCachesDir.listFiles();
+if (files != null)
 {
-if (!file.isFile())
-continue; // someone's been messing with our directory.  
naughty!
-
-if (file.getName().endsWith(cacheType.toString())
-|| file.getName().endsWith(String.format(%s-%s.db, 
cacheType.toString(), CURRENT_VERSION)))
+for (File file : files)
 {
-if (!file.delete())
-logger.warn(Failed to delete {}, 
file.getAbsolutePath());
+if (!file.isFile())
+continue; // someone's been messing with our 
directory.  naughty!
+
+if (file.getName().endsWith(cacheType.toString())
+|| 
file.getName().endsWith(String.format(%s-%s.db, cacheType.toString(), 
CURRENT_VERSION)))
+{
+if (!file.delete())
+logger.warn(Failed to delete {}, 
file.getAbsolutePath());
+}
 }
 }
+else
+logger.warn(Could not list files in {}, savedCachesDir);
 }
 }

[1/2] git commit: Avoid NPE when listing saved caches directory

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1.0 cde566629 - ef099c317


Avoid NPE when listing saved caches directory

Patch by marcuse; reviewed by yukim for CASSANDRA-7632


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1a0aaf04
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1a0aaf04
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1a0aaf04

Branch: refs/heads/cassandra-2.1.0
Commit: 1a0aaf04986155eae45b2685d234b928866b681c
Parents: 892bf55
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jul 31 07:53:33 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jul 31 07:53:33 2014 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java | 23 
 2 files changed, 15 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1a0aaf04/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a6fc837..1fcb556 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -22,6 +22,7 @@
  * Fix error when doing reversed queries with static columns (CASSANDRA-7490)
  * Backport CASSANDRA-6747 (CASSANDRA-7560)
  * Track max/min timestamps for range tombstones (CASSANDRA-7647)
+ * Fix NPE when listing saved caches dir (CASSANDRA-7632)
 Merged from 1.2:
  * Set correct stream ID on responses when non-Exception Throwables
are thrown while handling native protocol messages (CASSANDRA-7470)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1a0aaf04/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--
diff --git a/src/java/org/apache/cassandra/cache/AutoSavingCache.java 
b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
index 6554eb3..64234e2 100644
--- a/src/java/org/apache/cassandra/cache/AutoSavingCache.java
+++ b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
@@ -261,19 +261,24 @@ public class AutoSavingCacheK extends CacheKey, V 
extends InstrumentingCacheK
 {
 File savedCachesDir = new 
File(DatabaseDescriptor.getSavedCachesLocation());
 assert savedCachesDir.exists()  savedCachesDir.isDirectory();
-
-for (File file : savedCachesDir.listFiles())
+File[] files = savedCachesDir.listFiles();
+if (files != null)
 {
-if (!file.isFile())
-continue; // someone's been messing with our directory.  
naughty!
-
-if (file.getName().endsWith(cacheType.toString())
-|| file.getName().endsWith(String.format(%s-%s.db, 
cacheType.toString(), CURRENT_VERSION)))
+for (File file : files)
 {
-if (!file.delete())
-logger.warn(Failed to delete {}, 
file.getAbsolutePath());
+if (!file.isFile())
+continue; // someone's been messing with our 
directory.  naughty!
+
+if (file.getName().endsWith(cacheType.toString())
+|| 
file.getName().endsWith(String.format(%s-%s.db, cacheType.toString(), 
CURRENT_VERSION)))
+{
+if (!file.delete())
+logger.warn(Failed to delete {}, 
file.getAbsolutePath());
+}
 }
 }
+else
+logger.warn(Could not list files in {}, savedCachesDir);
 }
 }

[2/3] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0

Merge branch 'cassandra-2.0' into cassandra-2.1.0

Conflicts:
CHANGES.txt


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ef099c31
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ef099c31
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ef099c31

Branch: refs/heads/cassandra-2.1
Commit: ef099c317a59ac3161713d1cf6f2b113129bba09
Parents: cde5666 1a0aaf0
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jul 31 08:00:03 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jul 31 08:00:03 2014 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java | 23 
 2 files changed, 15 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef099c31/CHANGES.txt
--
diff --cc CHANGES.txt
index 3b2f35c,1fcb556..0ce0eaa
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,44 -1,10 +1,45 @@@
 -2.0.10
 +2.1.0-final
   * Remove shuffle and taketoken (CASSANDRA-7601)
 - * Switch liveRatio-related log messages to DEBUG (CASSANDRA-7467)
 - * (cqlsh) Add tab-completion for CREATE/DROP USER IF [NOT] EXISTS 
(CASSANDRA-7611)
 - * Always merge ranges owned by a single node (CASSANDRA-6930)
 - * Pig support for hadoop CqlInputFormat (CASSANDRA-6454)
 + * Clean up Windows batch scripts (CASSANDRA-7619)
 + * Fix native protocol drop user type notification (CASSANDRA-7571)
 + * Give read access to system.schema_usertypes to all authenticated users
 +   (CASSANDRA-7578)
 + * (cqlsh) Fix cqlsh display when zero rows are returned (CASSANDRA-7580)
 + * Get java version correctly when JAVA_TOOL_OPTIONS is set (CASSANDRA-7572)
 + * Fix NPE when dropping index from non-existent keyspace, AssertionError when
 +   dropping non-existent index with IF EXISTS (CASSANDRA-7590)
 + * Fix sstablelevelresetter hang (CASSANDRA-7614)
 + * (cqlsh) Fix deserialization of blobs (CASSANDRA-7603)
 + * Use keyspace updated schema change message for UDT changes in v1 and
 +   v2 protocols (CASSANDRA-7617)
 + * Fix tracing of range slices and secondary index lookups that are local
 +   to the coordinator (CASSANDRA-7599)
 + * Set -Dcassandra.storagedir for all tool shell scripts (CASSANDRA-7587)
 + * Don't swap max/min col names when mutating sstable metadata 
(CASSANDRA-7596)
 + * (cqlsh) Correctly handle paged result sets (CASSANDRA-7625)
 + * (cqlsh) Improve waiting for a trace to complete (CASSANDRA-7626)
 + * Fix tracing of concurrent range slices and 2ary index queries 
(CASSANDRA-7626)
 +Merged from 2.0:
   * Fix ReversedType(DateType) mapping to native protocol (CASSANDRA-7576)
 + * Always merge ranges owned by a single node (CASSANDRA-6930)
 + * Track max/min timestamps for range tombstones (CASSANDRA-7647)
++ * Fix NPE when listing saved caches dir (CASSANDRA-7632)
 +
 +
 +2.1.0-rc4
 + * Fix word count hadoop example (CASSANDRA-7200)
 + * Updated memtable_cleanup_threshold and memtable_flush_writers defaults 
 +   (CASSANDRA-7551)
 + * (Windows) fix startup when WMI memory query fails (CASSANDRA-7505)
 + * Anti-compaction proceeds if any part of the repair failed (CASANDRA-7521)
 + * Add missing table name to DROP INDEX responses and notifications 
(CASSANDRA-7539)
 + * Bump CQL version to 3.2.0 and update CQL documentation (CASSANDRA-7527)
 + * Fix configuration error message when running nodetool ring (CASSANDRA-7508)
 + * Support conditional updates, tuple type, and the v3 protocol in cqlsh 
(CASSANDRA-7509)
 + * Handle queries on multiple secondary index types (CASSANDRA-7525)
 + * Fix cqlsh authentication with v3 native protocol (CASSANDRA-7564)
 + * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)
 +Merged from 2.0:
   * (Windows) force range-based repair to non-sequential mode (CASSANDRA-7541)
   * Fix range merging when DES scores are zero (CASSANDRA-7535)
   * Warn when SSL certificates have expired (CASSANDRA-7528)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef099c31/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--

[3/3] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1

Merge branch 'cassandra-2.1.0' into cassandra-2.1


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/63407db7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/63407db7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/63407db7

Branch: refs/heads/cassandra-2.1
Commit: 63407db7e946bbf5aa796367375fd9cb46ba36c4
Parents: 40d7bdf ef099c3
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jul 31 08:00:30 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jul 31 08:00:30 2014 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java | 23 
 2 files changed, 15 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/63407db7/CHANGES.txt
--

[2/2] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0

Merge branch 'cassandra-2.0' into cassandra-2.1.0

Conflicts:
CHANGES.txt


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ef099c31
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ef099c31
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ef099c31

Branch: refs/heads/cassandra-2.1.0
Commit: ef099c317a59ac3161713d1cf6f2b113129bba09
Parents: cde5666 1a0aaf0
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jul 31 08:00:03 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jul 31 08:00:03 2014 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java | 23 
 2 files changed, 15 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef099c31/CHANGES.txt
--
diff --cc CHANGES.txt
index 3b2f35c,1fcb556..0ce0eaa
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,44 -1,10 +1,45 @@@
 -2.0.10
 +2.1.0-final
   * Remove shuffle and taketoken (CASSANDRA-7601)
 - * Switch liveRatio-related log messages to DEBUG (CASSANDRA-7467)
 - * (cqlsh) Add tab-completion for CREATE/DROP USER IF [NOT] EXISTS 
(CASSANDRA-7611)
 - * Always merge ranges owned by a single node (CASSANDRA-6930)
 - * Pig support for hadoop CqlInputFormat (CASSANDRA-6454)
 + * Clean up Windows batch scripts (CASSANDRA-7619)
 + * Fix native protocol drop user type notification (CASSANDRA-7571)
 + * Give read access to system.schema_usertypes to all authenticated users
 +   (CASSANDRA-7578)
 + * (cqlsh) Fix cqlsh display when zero rows are returned (CASSANDRA-7580)
 + * Get java version correctly when JAVA_TOOL_OPTIONS is set (CASSANDRA-7572)
 + * Fix NPE when dropping index from non-existent keyspace, AssertionError when
 +   dropping non-existent index with IF EXISTS (CASSANDRA-7590)
 + * Fix sstablelevelresetter hang (CASSANDRA-7614)
 + * (cqlsh) Fix deserialization of blobs (CASSANDRA-7603)
 + * Use keyspace updated schema change message for UDT changes in v1 and
 +   v2 protocols (CASSANDRA-7617)
 + * Fix tracing of range slices and secondary index lookups that are local
 +   to the coordinator (CASSANDRA-7599)
 + * Set -Dcassandra.storagedir for all tool shell scripts (CASSANDRA-7587)
 + * Don't swap max/min col names when mutating sstable metadata 
(CASSANDRA-7596)
 + * (cqlsh) Correctly handle paged result sets (CASSANDRA-7625)
 + * (cqlsh) Improve waiting for a trace to complete (CASSANDRA-7626)
 + * Fix tracing of concurrent range slices and 2ary index queries 
(CASSANDRA-7626)
 +Merged from 2.0:
   * Fix ReversedType(DateType) mapping to native protocol (CASSANDRA-7576)
 + * Always merge ranges owned by a single node (CASSANDRA-6930)
 + * Track max/min timestamps for range tombstones (CASSANDRA-7647)
++ * Fix NPE when listing saved caches dir (CASSANDRA-7632)
 +
 +
 +2.1.0-rc4
 + * Fix word count hadoop example (CASSANDRA-7200)
 + * Updated memtable_cleanup_threshold and memtable_flush_writers defaults 
 +   (CASSANDRA-7551)
 + * (Windows) fix startup when WMI memory query fails (CASSANDRA-7505)
 + * Anti-compaction proceeds if any part of the repair failed (CASANDRA-7521)
 + * Add missing table name to DROP INDEX responses and notifications 
(CASSANDRA-7539)
 + * Bump CQL version to 3.2.0 and update CQL documentation (CASSANDRA-7527)
 + * Fix configuration error message when running nodetool ring (CASSANDRA-7508)
 + * Support conditional updates, tuple type, and the v3 protocol in cqlsh 
(CASSANDRA-7509)
 + * Handle queries on multiple secondary index types (CASSANDRA-7525)
 + * Fix cqlsh authentication with v3 native protocol (CASSANDRA-7564)
 + * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)
 +Merged from 2.0:
   * (Windows) force range-based repair to non-sequential mode (CASSANDRA-7541)
   * Fix range merging when DES scores are zero (CASSANDRA-7535)
   * Warn when SSL certificates have expired (CASSANDRA-7528)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef099c31/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--

[4/4] git commit: Merge branch 'cassandra-2.1' into trunk

Merge branch 'cassandra-2.1' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/90ade6b4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/90ade6b4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/90ade6b4

Branch: refs/heads/trunk
Commit: 90ade6b45921c1a102cf97fa3fea7fca8462a085
Parents: a88c7e1 63407db
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jul 31 08:00:42 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jul 31 08:00:42 2014 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java | 23 
 2 files changed, 15 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/90ade6b4/CHANGES.txt
--

[1/4] git commit: Avoid NPE when listing saved caches directory

Repository: cassandra
Updated Branches:
  refs/heads/trunk a88c7e10f - 90ade6b45


Avoid NPE when listing saved caches directory

Patch by marcuse; reviewed by yukim for CASSANDRA-7632


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1a0aaf04
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1a0aaf04
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1a0aaf04

Branch: refs/heads/trunk
Commit: 1a0aaf04986155eae45b2685d234b928866b681c
Parents: 892bf55
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jul 31 07:53:33 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jul 31 07:53:33 2014 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java | 23 
 2 files changed, 15 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1a0aaf04/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a6fc837..1fcb556 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -22,6 +22,7 @@
  * Fix error when doing reversed queries with static columns (CASSANDRA-7490)
  * Backport CASSANDRA-6747 (CASSANDRA-7560)
  * Track max/min timestamps for range tombstones (CASSANDRA-7647)
+ * Fix NPE when listing saved caches dir (CASSANDRA-7632)
 Merged from 1.2:
  * Set correct stream ID on responses when non-Exception Throwables
are thrown while handling native protocol messages (CASSANDRA-7470)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1a0aaf04/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--
diff --git a/src/java/org/apache/cassandra/cache/AutoSavingCache.java 
b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
index 6554eb3..64234e2 100644
--- a/src/java/org/apache/cassandra/cache/AutoSavingCache.java
+++ b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
@@ -261,19 +261,24 @@ public class AutoSavingCacheK extends CacheKey, V 
extends InstrumentingCacheK
 {
 File savedCachesDir = new 
File(DatabaseDescriptor.getSavedCachesLocation());
 assert savedCachesDir.exists()  savedCachesDir.isDirectory();
-
-for (File file : savedCachesDir.listFiles())
+File[] files = savedCachesDir.listFiles();
+if (files != null)
 {
-if (!file.isFile())
-continue; // someone's been messing with our directory.  
naughty!
-
-if (file.getName().endsWith(cacheType.toString())
-|| file.getName().endsWith(String.format(%s-%s.db, 
cacheType.toString(), CURRENT_VERSION)))
+for (File file : files)
 {
-if (!file.delete())
-logger.warn(Failed to delete {}, 
file.getAbsolutePath());
+if (!file.isFile())
+continue; // someone's been messing with our 
directory.  naughty!
+
+if (file.getName().endsWith(cacheType.toString())
+|| 
file.getName().endsWith(String.format(%s-%s.db, cacheType.toString(), 
CURRENT_VERSION)))
+{
+if (!file.delete())
+logger.warn(Failed to delete {}, 
file.getAbsolutePath());
+}
 }
 }
+else
+logger.warn(Could not list files in {}, savedCachesDir);
 }
 }

[3/4] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1

Merge branch 'cassandra-2.1.0' into cassandra-2.1


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/63407db7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/63407db7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/63407db7

Branch: refs/heads/trunk
Commit: 63407db7e946bbf5aa796367375fd9cb46ba36c4
Parents: 40d7bdf ef099c3
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jul 31 08:00:30 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jul 31 08:00:30 2014 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java | 23 
 2 files changed, 15 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/63407db7/CHANGES.txt
--

[2/4] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0

Merge branch 'cassandra-2.0' into cassandra-2.1.0

Conflicts:
CHANGES.txt


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ef099c31
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ef099c31
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ef099c31

Branch: refs/heads/trunk
Commit: ef099c317a59ac3161713d1cf6f2b113129bba09
Parents: cde5666 1a0aaf0
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jul 31 08:00:03 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jul 31 08:00:03 2014 +0200

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java | 23 
 2 files changed, 15 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef099c31/CHANGES.txt
--
diff --cc CHANGES.txt
index 3b2f35c,1fcb556..0ce0eaa
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,44 -1,10 +1,45 @@@
 -2.0.10
 +2.1.0-final
   * Remove shuffle and taketoken (CASSANDRA-7601)
 - * Switch liveRatio-related log messages to DEBUG (CASSANDRA-7467)
 - * (cqlsh) Add tab-completion for CREATE/DROP USER IF [NOT] EXISTS 
(CASSANDRA-7611)
 - * Always merge ranges owned by a single node (CASSANDRA-6930)
 - * Pig support for hadoop CqlInputFormat (CASSANDRA-6454)
 + * Clean up Windows batch scripts (CASSANDRA-7619)
 + * Fix native protocol drop user type notification (CASSANDRA-7571)
 + * Give read access to system.schema_usertypes to all authenticated users
 +   (CASSANDRA-7578)
 + * (cqlsh) Fix cqlsh display when zero rows are returned (CASSANDRA-7580)
 + * Get java version correctly when JAVA_TOOL_OPTIONS is set (CASSANDRA-7572)
 + * Fix NPE when dropping index from non-existent keyspace, AssertionError when
 +   dropping non-existent index with IF EXISTS (CASSANDRA-7590)
 + * Fix sstablelevelresetter hang (CASSANDRA-7614)
 + * (cqlsh) Fix deserialization of blobs (CASSANDRA-7603)
 + * Use keyspace updated schema change message for UDT changes in v1 and
 +   v2 protocols (CASSANDRA-7617)
 + * Fix tracing of range slices and secondary index lookups that are local
 +   to the coordinator (CASSANDRA-7599)
 + * Set -Dcassandra.storagedir for all tool shell scripts (CASSANDRA-7587)
 + * Don't swap max/min col names when mutating sstable metadata 
(CASSANDRA-7596)
 + * (cqlsh) Correctly handle paged result sets (CASSANDRA-7625)
 + * (cqlsh) Improve waiting for a trace to complete (CASSANDRA-7626)
 + * Fix tracing of concurrent range slices and 2ary index queries 
(CASSANDRA-7626)
 +Merged from 2.0:
   * Fix ReversedType(DateType) mapping to native protocol (CASSANDRA-7576)
 + * Always merge ranges owned by a single node (CASSANDRA-6930)
 + * Track max/min timestamps for range tombstones (CASSANDRA-7647)
++ * Fix NPE when listing saved caches dir (CASSANDRA-7632)
 +
 +
 +2.1.0-rc4
 + * Fix word count hadoop example (CASSANDRA-7200)
 + * Updated memtable_cleanup_threshold and memtable_flush_writers defaults 
 +   (CASSANDRA-7551)
 + * (Windows) fix startup when WMI memory query fails (CASSANDRA-7505)
 + * Anti-compaction proceeds if any part of the repair failed (CASANDRA-7521)
 + * Add missing table name to DROP INDEX responses and notifications 
(CASSANDRA-7539)
 + * Bump CQL version to 3.2.0 and update CQL documentation (CASSANDRA-7527)
 + * Fix configuration error message when running nodetool ring (CASSANDRA-7508)
 + * Support conditional updates, tuple type, and the v3 protocol in cqlsh 
(CASSANDRA-7509)
 + * Handle queries on multiple secondary index types (CASSANDRA-7525)
 + * Fix cqlsh authentication with v3 native protocol (CASSANDRA-7564)
 + * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)
 +Merged from 2.0:
   * (Windows) force range-based repair to non-sequential mode (CASSANDRA-7541)
   * Fix range merging when DES scores are zero (CASSANDRA-7535)
   * Warn when SSL certificates have expired (CASSANDRA-7528)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef099c31/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--

[jira] [Updated] (CASSANDRA-7636) Data is not filtered out when using WHERE clause on cluster column on Column Family with row cache on.


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-7636:
---

Attachment: 0001-actually-filter-the-cached-result.patch

Attaching patch to actually use the filter when we get a cache hit

 Data is not filtered out when using WHERE clause on cluster column on Column 
 Family with row cache on.
 --

 Key: CASSANDRA-7636
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7636
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.1.0-rc4
Reporter: Krzysztof Zarzycki
Assignee: Marcus Eriksson
 Fix For: 2.1.0

 Attachments: 0001-actually-filter-the-cached-result.patch


 My pretty simplified case looks like the following:
 I create a table with partition and cluster column. I set key caching to NONE 
 and row caching to ALL.  
 When I'm running some SELECTs with WHERE clause filtering on cluster columns, 
 the rows sometimes are not getting filtered out. When? Probably when the row 
 gets loaded to row cache (By some previous query).
 Look at this scenario: 
 {code}
 cqlsh:xxx create KEYSPACE test_keyspace WITH replication = {'class': 
 'SimpleStrategy', 'replication_factor': 1};
 cqlsh:xxx use test_keyspace ;
 cqlsh:test_keyspace CREATE TABLE test (p1 bigint, c1 int, PRIMARY KEY (p1, 
 c1) )  WITH caching = '{keys:NONE, rows_per_partition:ALL}';
 cqlsh:test_keyspace insert into test (p1, c1 ) values ( 123, 10);
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
 (0 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  9;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 {code}
 Running the same scenario, but with row cache turned OFF works fine. 
 The filtering on other (partition) columns runs fine. Only the clustering 
 column is somewhat malfunctioning. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7636) Data is not filtered out when using WHERE clause on cluster column on Column Family with row cache on.

2014-07-31 Thread Krzysztof Zarzycki (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080640#comment-14080640
 ] 

Krzysztof Zarzycki commented on CASSANDRA-7636:
---

I confirm that the patch works! 

 Data is not filtered out when using WHERE clause on cluster column on Column 
 Family with row cache on.
 --

 Key: CASSANDRA-7636
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7636
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.1.0-rc4
Reporter: Krzysztof Zarzycki
Assignee: Marcus Eriksson
 Fix For: 2.1.0

 Attachments: 0001-actually-filter-the-cached-result.patch


 My pretty simplified case looks like the following:
 I create a table with partition and cluster column. I set key caching to NONE 
 and row caching to ALL.  
 When I'm running some SELECTs with WHERE clause filtering on cluster columns, 
 the rows sometimes are not getting filtered out. When? Probably when the row 
 gets loaded to row cache (By some previous query).
 Look at this scenario: 
 {code}
 cqlsh:xxx create KEYSPACE test_keyspace WITH replication = {'class': 
 'SimpleStrategy', 'replication_factor': 1};
 cqlsh:xxx use test_keyspace ;
 cqlsh:test_keyspace CREATE TABLE test (p1 bigint, c1 int, PRIMARY KEY (p1, 
 c1) )  WITH caching = '{keys:NONE, rows_per_partition:ALL}';
 cqlsh:test_keyspace insert into test (p1, c1 ) values ( 123, 10);
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
 (0 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  9;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 {code}
 Running the same scenario, but with row cache turned OFF works fine. 
 The filtering on other (partition) columns runs fine. Only the clustering 
 column is somewhat malfunctioning. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-7636) Data is not filtered out when using WHERE clause on cluster column on Column Family with row cache on.

2014-07-31 Thread Krzysztof Zarzycki (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080640#comment-14080640
 ] 

Krzysztof Zarzycki edited comment on CASSANDRA-7636 at 7/31/14 8:23 AM:


I confirm that the patch works! Thank you:)

Now I understand it has to go through review and then you'll add it to the new 
RC, right?


was (Author: zarzyk):
I confirm that the patch works! 

 Data is not filtered out when using WHERE clause on cluster column on Column 
 Family with row cache on.
 --

 Key: CASSANDRA-7636
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7636
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.1.0-rc4
Reporter: Krzysztof Zarzycki
Assignee: Marcus Eriksson
 Fix For: 2.1.0

 Attachments: 0001-actually-filter-the-cached-result.patch


 My pretty simplified case looks like the following:
 I create a table with partition and cluster column. I set key caching to NONE 
 and row caching to ALL.  
 When I'm running some SELECTs with WHERE clause filtering on cluster columns, 
 the rows sometimes are not getting filtered out. When? Probably when the row 
 gets loaded to row cache (By some previous query).
 Look at this scenario: 
 {code}
 cqlsh:xxx create KEYSPACE test_keyspace WITH replication = {'class': 
 'SimpleStrategy', 'replication_factor': 1};
 cqlsh:xxx use test_keyspace ;
 cqlsh:test_keyspace CREATE TABLE test (p1 bigint, c1 int, PRIMARY KEY (p1, 
 c1) )  WITH caching = '{keys:NONE, rows_per_partition:ALL}';
 cqlsh:test_keyspace insert into test (p1, c1 ) values ( 123, 10);
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
 (0 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  9;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 {code}
 Running the same scenario, but with row cache turned OFF works fine. 
 The filtering on other (partition) columns runs fine. Only the clustering 
 column is somewhat malfunctioning. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7636) Data is not filtered out when using WHERE clause on cluster column on Column Family with row cache on.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080642#comment-14080642
 ] 

Marcus Eriksson commented on CASSANDRA-7636:


bq. it has to go through review and then you'll add it to the new RC, right?
correct

 Data is not filtered out when using WHERE clause on cluster column on Column 
 Family with row cache on.
 --

 Key: CASSANDRA-7636
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7636
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.1.0-rc4
Reporter: Krzysztof Zarzycki
Assignee: Marcus Eriksson
 Fix For: 2.1.0

 Attachments: 0001-actually-filter-the-cached-result.patch


 My pretty simplified case looks like the following:
 I create a table with partition and cluster column. I set key caching to NONE 
 and row caching to ALL.  
 When I'm running some SELECTs with WHERE clause filtering on cluster columns, 
 the rows sometimes are not getting filtered out. When? Probably when the row 
 gets loaded to row cache (By some previous query).
 Look at this scenario: 
 {code}
 cqlsh:xxx create KEYSPACE test_keyspace WITH replication = {'class': 
 'SimpleStrategy', 'replication_factor': 1};
 cqlsh:xxx use test_keyspace ;
 cqlsh:test_keyspace CREATE TABLE test (p1 bigint, c1 int, PRIMARY KEY (p1, 
 c1) )  WITH caching = '{keys:NONE, rows_per_partition:ALL}';
 cqlsh:test_keyspace insert into test (p1, c1 ) values ( 123, 10);
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
 (0 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  9;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 {code}
 Running the same scenario, but with row cache turned OFF works fine. 
 The filtering on other (partition) columns runs fine. Only the clustering 
 column is somewhat malfunctioning. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7642) Adaptive Consistency

[
https://issues.apache.org/jira/browse/CASSANDRA-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080697#comment-14080697
]

Robert Stupp commented on CASSANDRA-7642:
-

Do you want a consistency-level that ensures that the quorum is met in all
currently live reachable DCs ?

E.g. if there are 3 DCs and one DC is down/unreachable/whatever, that CL should
only consider the 2 remaining, reachable DCs and enforce quorum in each of
them? I think this is a situation where EACH_QUORUM fails and QUORUM is not
feasible (_not DC-aware_).

IMO that (something like _LIVE_QUORUM_) would be a good thing for some
requirements. It would also offer operations the possibility to take an entire
DC down while the application can still use strong worldwide consistency.

Adaptive Consistency

Key: CASSANDRA-7642
URL: https://issues.apache.org/jira/browse/CASSANDRA-7642
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Rustam Aliyev
Fix For: 3.0

h4. Problem
At minimum, application requires consistency level of X, which must be fault
tolerant CL. However, when there is no failure it would be advantageous to
use stronger consistency Y (YX).
h4. Suggestion
Application defines minimum (X) and maximum (Y) consistency levels. C* can
apply adaptive consistency logic to use Y whenever possible and downgrade to
X when failure occurs.
Implementation should not negatively impact performance. Therefore, state has
to be maintained globally (not per request).
h4. Example
{{MIN_CL=LOCAL_QUORUM}}
{{MAX_CL=EACH_QUORUM}}
h4. Use Case
Consider a case where user wants to maximize their uptime and consistency.
They designing a system using C* where transactions are read/written with
LOCAL_QUORUM and distributed across 2 DCs. Occasional inconsistencies between
DCs can be tolerated. R/W with LOCAL_QUORUM is satisfactory in most of the
cases.
Application requires new transactions to be read back right after they were
generated. Write and read could be done through different DCs (no
stickiness). In some cases when user writes into DC1 and reads immediately
from DC2, replication delay may cause problems. Transaction won't show up on
read in DC2, user will retry and create duplicate transaction. Occasional
duplicates are fine and the goal is to minimize number of dups.
Therefore, we want to perform writes with stronger consistency (EACH_QUORUM)
whenever possible without compromising on availability. Using adaptive
consistency they should be able to define:
{{Read CL = LOCAL_QUORUM}}
{{Write CL = ADAPTIVE (MIN:LOCAL_QUORUM, MAX:EACH_QUORUM)}}
Similar scenario can be described for {{Write CL = ADAPTIVE (MIN:QUORUM,
MAX:ALL)}} case.
h4. Criticism
# This functionality can/should be implemented by user himself.
bq. It will be hard for an average user to implement topology monitoring and
state machine. Moreover, this is a pattern which repeats.
# Transparent downgrading violates the CL contract, and that contract
considered be just about the most important element of Cassandra's runtime
behavior.
bq.Fully transparent downgrading without any contract is dangerous. However,
would it be problem if we specify explicitly only two discrete CL levels -
MIN_CL and MAX_CL?
# If you have split brain DCs (partitioned in CAP), you have to sacrifice
either consistency or availability, and auto downgrading sacrifices the
consistency in dangerous ways if the application isn't designed to handle it.
And if the application is designed to handle it, then it should be able to
handle it in normal circumstances, not just degraded/extraordinary ones.
bq. Agreed. Application should be designed for MIN_CL. In that case, MAX_CL
will not be causing much harm, only adding flexibility.
# It might be a better idea to loudly downgrade, instead of silently
downgrading, meaning that the client code does an explicit retry with lower
consistency on failure and takes some other kind of action to attempt to
inform either users or operators of the problem. The silent part of the
downgrading which could be dangerous.
bq. There are certainly cases where user should be informed when consistency
changes in order to perform custom action. For this purpose we could
allow/require user to register callback function which will be triggered when
consistency level changes. Best practices could be enforced by requiring
callback.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7642) Adaptive Consistency

2014-07-31 Thread Rustam Aliyev (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080706#comment-14080706
]

Rustam Aliyev commented on CASSANDRA-7642:
--

Yes. I think I finally found a simple way to explain the problem :).

Robert, regarding DowngradingConsistencyRetryPolicy see my first comment on top
- it's useless.

Adaptive Consistency

Key: CASSANDRA-7642
URL: https://issues.apache.org/jira/browse/CASSANDRA-7642
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Rustam Aliyev
Fix For: 3.0

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)

[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080708#comment-14080708
]

Robert Stupp commented on CASSANDRA-7438:
-

bq. Yeah it works in unix, but the problem is i don't have a handle since its a
temp file after restart. So it is a best effort for cleanups.

It's a really sick problem. I changed our Snappy integration a similar way. IMO
there's no better solution than messing the temp dir.

bq. The problem is it produces a circular dependency

Ah - I meant that lruc code is copied to C* code base (if the others agree).
But this could be a second step since it's only a bit of refactoring.

Serializing Row cache alternative (Fully off heap)
--

Key: CASSANDRA-7438
URL: https://issues.apache.org/jira/browse/CASSANDRA-7438
Project: Cassandra
Issue Type: Improvement
Components: Core
Environment: Linux
Reporter: Vijay
Assignee: Vijay
Labels: performance
Fix For: 3.0

Attachments: 0001-CASSANDRA-7438.patch

Currently SerializingCache is partially off heap, keys are still stored in
JVM heap as BB,
* There is a higher GC costs for a reasonably big cache.
* Some users have used the row cache efficiently in production for better
results, but this requires careful tunning.
* Overhead in Memory for the cache entries are relatively high.
So the proposal for this ticket is to move the LRU cache logic completely off
heap and use JNI to interact with cache. We might want to ensure that the new
implementation match the existing API's (ICache), and the implementation
needs to have safe memory access, low overhead in memory and less memcpy's
(As much as possible).
We might also want to make this cache configurable.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7395) Support for pure user-defined functions (UDF)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080712#comment-14080712
 ] 

Robert Stupp commented on CASSANDRA-7395:
-

[~thobbs] do you have time for another review? The patches reflect the changes 
above. https://github.com/snazy/cassandra/tree/7395 and 
https://github.com/snazy/cassandra/tree/7562-udf-java contain the same (just 
merged trunk yesturday).

If this ticket is ok, I could move on to CASSANDRA-7562 and either 
CASSANDRA-7557 or CASSANDRA-7526.

 Support for pure user-defined functions (UDF)
 -

 Key: CASSANDRA-7395
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7395
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Robert Stupp
  Labels: cql
 Fix For: 3.0

 Attachments: 7395.txt, udf-create-syntax.png, udf-drop-syntax.png


 We have some tickets for various aspects of UDF (CASSANDRA-4914, 
 CASSANDRA-5970, CASSANDRA-4998) but they all suffer from various degrees of 
 ocean-boiling.
 Let's start with something simple: allowing pure user-defined functions in 
 the SELECT clause of a CQL query.  That's it.
 By pure I mean, must depend only on the input parameters.  No side effects. 
  No exposure to C* internals.  Column values in, result out.  
 http://en.wikipedia.org/wiki/Pure_function



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7642) Adaptive Consistency

[
https://issues.apache.org/jira/browse/CASSANDRA-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080734#comment-14080734
]

Robert Stupp commented on CASSANDRA-7642:
-

So - _LIVE_QUORUM_ is what you want?

Adaptive Consistency

Key: CASSANDRA-7642
URL: https://issues.apache.org/jira/browse/CASSANDRA-7642
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Rustam Aliyev
Fix For: 3.0

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7642) Adaptive Consistency

2014-07-31 Thread Rustam Aliyev (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080746#comment-14080746
]

Rustam Aliyev commented on CASSANDRA-7642:
--

That will be better than nothing, but that means at least 3 DCs. Depending on
the cluster size this can be very expensive requirement (imagine case with
hundreds of nodes in each DC).

I'd like to see if we can come up with solution which will work with 2 DCs.

With AC one can read and write with (MIN:LOCAL_Q, MAX:EACH_Q) and achieve same
goal at no extra cost.

Adaptive Consistency

Key: CASSANDRA-7642
URL: https://issues.apache.org/jira/browse/CASSANDRA-7642
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Rustam Aliyev
Fix For: 3.0

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7642) Adaptive Consistency

[
https://issues.apache.org/jira/browse/CASSANDRA-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080749#comment-14080749
]

Robert Stupp commented on CASSANDRA-7642:
-

Nope - it would mean enforce quorum in each live reachable DC and works
with 1, 2, 3, 10 DCs - it's not a quorum over DCs.

Adaptive Consistency

Key: CASSANDRA-7642
URL: https://issues.apache.org/jira/browse/CASSANDRA-7642
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Rustam Aliyev
Fix For: 3.0

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7653) Add role based access control to Cassandra

Mike Adamson created CASSANDRA-7653:
---

 Summary: Add role based access control to Cassandra
 Key: CASSANDRA-7653
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7653
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Mike Adamson
 Fix For: 3.0


The current authentication model supports granting permissions to individual 
users. While this is OK for small or medium organizations wanting to implement 
authorization, it does not work well in large organizations because of the 
overhead of having to maintain the permissions for each user.

Introducing roles into the authentication model would sets of permissions to be 
controlled in one place and then the role granted to users. Roles should also 
be able to be granted to other roles to allow hierarchical sets of permissions 
to be built up.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7653) Add role based access control to Cassandra


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Adamson updated CASSANDRA-7653:


Attachment: 7653.patch

 Add role based access control to Cassandra
 --

 Key: CASSANDRA-7653
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7653
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Mike Adamson
 Fix For: 3.0

 Attachments: 7653.patch


 The current authentication model supports granting permissions to individual 
 users. While this is OK for small or medium organizations wanting to 
 implement authorization, it does not work well in large organizations because 
 of the overhead of having to maintain the permissions for each user.
 Introducing roles into the authentication model would sets of permissions to 
 be controlled in one place and then the role granted to users. Roles should 
 also be able to be granted to other roles to allow hierarchical sets of 
 permissions to be built up.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7653) Add role based access control to Cassandra

[
https://issues.apache.org/jira/browse/CASSANDRA-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Adamson updated CASSANDRA-7653:

Description:
The current authentication model supports granting permissions to individual
users. While this is OK for small or medium organizations wanting to implement
authorization, it does not work well in large organizations because of the
overhead of having to maintain the permissions for each user.

Introducing roles into the authentication model would allow sets of permissions
to be controlled in one place as a role and then the role granted to users.
Roles should also be able to be granted to other roles to allow hierarchical
sets of permissions to be built up.

was:
The current authentication model supports granting permissions to individual
users. While this is OK for small or medium organizations wanting to implement
authorization, it does not work well in large organizations because of the
overhead of having to maintain the permissions for each user.

Introducing roles into the authentication model would sets of permissions to be
controlled in one place and then the role granted to users. Roles should also
be able to be granted to other roles to allow hierarchical sets of permissions
to be built up.

Add role based access control to Cassandra
--

Key: CASSANDRA-7653
URL: https://issues.apache.org/jira/browse/CASSANDRA-7653
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Mike Adamson
Fix For: 3.0

Attachments: 7653.patch

The current authentication model supports granting permissions to individual
users. While this is OK for small or medium organizations wanting to
implement authorization, it does not work well in large organizations because
of the overhead of having to maintain the permissions for each user.
Introducing roles into the authentication model would allow sets of
permissions to be controlled in one place as a role and then the role granted
to users. Roles should also be able to be granted to other roles to allow
hierarchical sets of permissions to be built up.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-7653) Add role based access control to Cassandra


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080753#comment-14080753
 ] 

Mike Adamson edited comment on CASSANDRA-7653 at 7/31/14 11:17 AM:
---

h3. Role Based Access Control In Cassandra
The purpose of this comment is to define the changes made to the authentication 
and authorization models to support role based access control in the attached 
7653.patch
h4. Overview
Roles will be able to have permissions granted to then in the same way as they 
can be granted to a user. Roles can be granted to users and other roles. When a 
role is granted to a user or other role (grantee) the grantee receives the 
permissions that have been granted to the role. When a role is revoked from a 
user or other role (revokee) the revokee loses the permissions that have been 
granted to the role.
h4. CQL3 Grammar Changes
The following grammar changes to CQL3 are needed to support roles:
h6. CREATE ROLE rolename
New statement to add a role to the system. The role is added to the 
*system_auth.roles* table.
h6. DROP ROLE rolename
New statement to remove a role from the system. The role is removed from the 
*system_auth.roles* table, any grants using the role are removed from the 
*system_auth.granted_roles* table and any permissions granted to it are removed 
from the *system_auth.role_permissions* table. 
h6. LIST ROLES \[OF \[ROLE rolename | USER username]] \[NORECURSIVE]
New to statement to list:
* No options:
** superuser - all the roles in the system (*system_auth.roles* table).
** non-superuser - all the roles available to the user
* OF ROLE rolename - of a specific role (the caller must be a superuser)
* OF USER username - of a specific user (any user if the caller is a 
superuser otherwise must be the same name as the caller)

If *NORECURSIVE* option is given then only direct grants to the grantee are 
listed. The default is to list roles recursively.

h6. GRANT permission ON resource TO \[\[USER] username | ROLE rolename]
Extension of existing statement to grant permissions to a role. Backward 
compatibility is maintained by making the *USER* part of the syntax optional.
h6. REVOKE permission ON resource FROM \[\[USER] username | ROLE 
rolename]
Extension of existing statement to revoke permissions from a role. Backward 
compatibility is maintained by making the *USER* part of the syntax optional.
h6. LIST permissionOrAll \[ON resource] \[OF \[\[USER] username | ROLE 
rolename] \[NORECURSIVE]
Extension of existing statement to list the permissions of a role. Backward 
compatibility is maintained by making the *USER* part of the syntax optional.

h4. Interface Changes
To support role the IRoleMapper and IRoleBasedAuthorizer interfaces have been 
added to support the granting of roles and the granting of permissions to 
roles. 
h4. Schema Changes
Existing auth tables are not being changed for this story but the following new 
tables are being added:
h6. system_auth.roles
{noformat}
CREATE TABLE system_auth.roles(role text, PRIMARY KEY(role))
{noformat}
h6. system_auth.granted_roles
{noformat}
CREATE TABLE system_auth.granted_roles(grantee text, type text,role 
text,PRIMARY KEY((grantee, type), role))
{noformat}
h6. system_auth.role_permissions
{noformat}
CREATE TABLE system_auth.role_permissions(role text, resource text, permissions 
settext, PRIMARY KEY(role, resource))
{noformat}


was (Author: mikea):
h3. Role Based Access Control In Cassandra
The purpose of this comment is to define the changes made to the authentication 
and authorization models to support role based authorization in the attached 
7653.patch
h4. Overview
Roles will be able to have permissions granted to then in the same way as they 
can be granted to a user. Roles can be granted to users and other roles. When a 
role is granted to a user or other role (grantee) the grantee receives the 
permissions that have been granted to the role. When a role is revoked from a 
user or other role (revokee) the revokee loses the permissions that have been 
granted to the role.
h4. CQL3 Grammar Changes
The following grammar changes to CQL3 are needed to support roles:
h6. CREATE ROLE rolename
New statement to add a role to the system. The role is added to the 
*system_auth.roles* table.
h6. DROP ROLE rolename
New statement to remove a role from the system. The role is removed from the 
*system_auth.roles* table, any grants using the role are removed from the 
*system_auth.granted_roles* table and any permissions granted to it are removed 
from the *system_auth.role_permissions* table. 
h6. LIST ROLES \[OF \[ROLE rolename | USER username]] \[NORECURSIVE]
New to statement to list:
* No options:
** superuser - all the roles in the system (*system_auth.roles* table).
** non-superuser - all the roles available to the user
* OF ROLE rolename - of a specific role (the caller must be a superuser)
* OF USER

[jira] [Comment Edited] (CASSANDRA-7653) Add role based access control to Cassandra


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080753#comment-14080753
 ] 

Mike Adamson edited comment on CASSANDRA-7653 at 7/31/14 11:16 AM:
---

h3. Role Based Access Control In Cassandra
The purpose of this comment is to define the changes made to the authentication 
and authorization models to support role based authorization in the attached 
7653.patch
h4. Overview
Roles will be able to have permissions granted to then in the same way as they 
can be granted to a user. Roles can be granted to users and other roles. When a 
role is granted to a user or other role (grantee) the grantee receives the 
permissions that have been granted to the role. When a role is revoked from a 
user or other role (revokee) the revokee loses the permissions that have been 
granted to the role.
h4. CQL3 Grammar Changes
The following grammar changes to CQL3 are needed to support roles:
h6. CREATE ROLE rolename
New statement to add a role to the system. The role is added to the 
*system_auth.roles* table.
h6. DROP ROLE rolename
New statement to remove a role from the system. The role is removed from the 
*system_auth.roles* table, any grants using the role are removed from the 
*system_auth.granted_roles* table and any permissions granted to it are removed 
from the *system_auth.role_permissions* table. 
h6. LIST ROLES \[OF \[ROLE rolename | USER username]] \[NORECURSIVE]
New to statement to list:
* No options:
** superuser - all the roles in the system (*system_auth.roles* table).
** non-superuser - all the roles available to the user
* OF ROLE rolename - of a specific role (the caller must be a superuser)
* OF USER username - of a specific user (any user if the caller is a 
superuser otherwise must be the same name as the caller)

If *NORECURSIVE* option is given then only direct grants to the grantee are 
listed. The default is to list roles recursively.

h6. GRANT permission ON resource TO \[\[USER] username | ROLE rolename]
Extension of existing statement to grant permissions to a role. Backward 
compatibility is maintained by making the *USER* part of the syntax optional.
h6. REVOKE permission ON resource FROM \[\[USER] username | ROLE 
rolename]
Extension of existing statement to revoke permissions from a role. Backward 
compatibility is maintained by making the *USER* part of the syntax optional.
h6. LIST permissionOrAll \[ON resource] \[OF \[\[USER] username | ROLE 
rolename] \[NORECURSIVE]
Extension of existing statement to list the permissions of a role. Backward 
compatibility is maintained by making the *USER* part of the syntax optional.

h4. Interface Changes
To support role the IRoleMapper and IRoleBasedAuthorizer interfaces have been 
added to support the granting of roles and the granting of permissions to 
roles. 
h4. Schema Changes
Existing auth tables are not being changed for this story but the following new 
tables are being added:
h6. system_auth.roles
{noformat}
CREATE TABLE system_auth.roles(role text, PRIMARY KEY(role))
{noformat}
h6. system_auth.granted_roles
{noformat}
CREATE TABLE system_auth.granted_roles(grantee text, type text,role 
text,PRIMARY KEY((grantee, type), role))
{noformat}
h6. system_auth.role_permissions
{noformat}
CREATE TABLE system_auth.role_permissions(role text, resource text, permissions 
settext, PRIMARY KEY(role, resource))
{noformat}


was (Author: mikea):
h3. Role Based Authorization In Cassandra
The purpose of this comment is to define the changes made to the authentication 
and authorization models to support role based authorization in the attached 
7653.patch
h4. Overview
Roles will be able to have permissions granted to then in the same way as they 
can be granted to a user. Roles can be granted to users and other roles. When a 
role is granted to a user or other role (grantee) the grantee receives the 
permissions that have been granted to the role. When a role is revoked from a 
user or other role (revokee) the revokee loses the permissions that have been 
granted to the role.
h4. CQL3 Grammar Changes
The following grammar changes to CQL3 are needed to support roles:
h6. CREATE ROLE rolename
New statement to add a role to the system. The role is added to the 
*system_auth.roles* table.
h6. DROP ROLE rolename
New statement to remove a role from the system. The role is removed from the 
*system_auth.roles* table, any grants using the role are removed from the 
*system_auth.granted_roles* table and any permissions granted to it are removed 
from the *system_auth.role_permissions* table. 
h6. LIST ROLES \[OF \[ROLE rolename | USER username]] \[NORECURSIVE]
New to statement to list:
* No options:
** superuser - all the roles in the system (*system_auth.roles* table).
** non-superuser - all the roles available to the user
* OF ROLE rolename - of a specific role (the caller must be a superuser)
* OF USER

[jira] [Commented] (CASSANDRA-7631) Allow Stress to write directly to SSTables


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080759#comment-14080759
 ] 

Benedict commented on CASSANDRA-7631:
-

Feel free to leave this one for me, as I'll be looking at stress soon anyway.

 Allow Stress to write directly to SSTables
 --

 Key: CASSANDRA-7631
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7631
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Russell Alexander Spitzer
Assignee: Russell Alexander Spitzer

 One common difficulty with benchmarking machines is the amount of time it 
 takes to initially load data. For machines with a large amount of ram this 
 becomes especially onerous because a very large amount of data needs to be 
 placed on the machine before page-cache can be circumvented. 
 To remedy this I suggest we add a top level flag to Cassandra-Stress which 
 would cause the tool to write directly to sstables rather than actually 
 performing CQL inserts. Internally this would use CQLSStable writer to write 
 directly to sstables while skipping any keys which are not owned by the node 
 stress is running on. The same stress command run on each node in the cluster 
 would then write unique sstables only containing data which that node is 
 responsible for. Following this no further network IO would be required to 
 distribute data as it would all already be correctly in place.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7654) CQL INSERT improvement

Robert Stupp created CASSANDRA-7654:
---

 Summary: CQL INSERT improvement
 Key: CASSANDRA-7654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7654
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Stupp


It would be nice to be able to add multiple rows using a single {{INSERT}}.
Restricted to the same partition.

For example:

Current behaviour:
{noformat}
INSERT INTO comp_key (key, num_val)
  VALUES ('foo', 1, 41);
INSERT INTO comp_key (key, num_val)
  VALUES ('foo', 2, 42);
{noformat}

Wanted behaviour:
{noformat}
INSERT INTO comp_key (key, num_val)
  VALUES
('foo', 1, 41),
('foo', 2, 42),
('foo', 3, 42),
('foo', 4, 42);
{noformat}

Assumed table def:
{noformat}
CREATE TABLE comp_key (
  key TEXT,
  clust   INT,
  num_val DECIMAL,
  PRIMARY KEY ( key, clust )
);
{noformat}




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7654) CQL INSERT improvement

2014-07-31 Thread Jack Krupansky (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080766#comment-14080766
 ] 

Jack Krupansky commented on CASSANDRA-7654:
---

1. For doc purposes, what is the rationale for restricting the insert to a 
single partition?

2. Will subsequent inserts occur if any of the inserts fail due to consistency 
or for any other reason?

3. Can the app assume that the inserts will be attempted in parallel?

4. Will the driver route the insert to the insert a node that owns that 
partition key?

4a. Should all of the inserts really be routed to the same node, or distributed 
according to RF? (Driver question.)

5. Is it also proposed to enhance the driver to support such a batch 
insertion of documents?
 

 CQL INSERT improvement
 --

 Key: CASSANDRA-7654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7654
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Stupp

 It would be nice to be able to add multiple rows using a single {{INSERT}}.
 Restricted to the same partition.
 For example:
 Current behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 1, 41);
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 2, 42);
 {noformat}
 Wanted behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES
 ('foo', 1, 41),
 ('foo', 2, 42),
 ('foo', 3, 42),
 ('foo', 4, 42);
 {noformat}
 Assumed table def:
 {noformat}
 CREATE TABLE comp_key (
   key TEXT,
   clust   INT,
   num_val DECIMAL,
   PRIMARY KEY ( key, clust )
 );
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7655) Slow repair on empty cluster

2014-07-31 Thread Jens Rantil (JIRA)

Jens Rantil created CASSANDRA-7655:
--

 Summary: Slow repair on empty cluster
 Key: CASSANDRA-7655
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7655
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jens Rantil
Priority: Minor


Background: I have done:
 * I've set up three (Datastax DSE) nodes with replication factor of 3. Each 
node has 256 vnodes. Each is running Cassandra 2.0.8.39, according to `cqlsh`.
 * [enabled 
authorization|http://www.datastax.com/documentation/cassandra/1.2/cassandra/security/secure_config_native_authorize_t.html]
 * [enabled 
authentication|http://www.datastax.com/documentation/cassandra/1.2/cassandra/security/secure_about_native_authenticate_c.html]
 * created a custom keyspace with replication factor and created a smaller 
table without putting any data into it.

For fun execute a `nodetool repair` in my terminal this takes _23 minutes_. 
This feels a bit slow to me for not having put _any_ data into my cluster. Is 
this expected? Or a bug?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7575) Custom 2i validation

2014-07-31 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrés de la Peña updated CASSANDRA-7575:
-

Attachment: 2i_validation_v2.patch

 Custom 2i validation
 

 Key: CASSANDRA-7575
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7575
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Reporter: Andrés de la Peña
Assignee: Andrés de la Peña
Priority: Minor
  Labels: 2i, cql3, secondaryIndex, secondary_index, select
 Fix For: 2.1.1

 Attachments: 2i_validation.patch, 2i_validation_v2.patch


 There are several projects using custom secondary indexes as an extension 
 point to integrate C* with other systems such as Solr or Lucene. The usual 
 approach is to embed third party indexing queries in CQL clauses. 
 For example, [DSE 
 Search|http://www.datastax.com/what-we-offer/products-services/datastax-enterprise]
  embeds Solr syntax this way:
 {code}
 SELECT title FROM solr WHERE solr_query='title:natio*';
 {code}
 [Stratio platform|https://github.com/Stratio/stratio-cassandra] embeds custom 
 JSON syntax for searching in Lucene indexes:
 {code}
 SELECT * FROM tweets WHERE lucene='{
 filter : {
 type: range,
 field: time,
 lower: 2014/04/25,
 upper: 2014/04/1
 },
 query  : {
 type: phrase, 
 field: body, 
 values: [big, data]
 },
 sort  : {fields: [ {field:time, reverse:true} ] }
 }';
 {code}
 Tuplejump [Stargate|http://tuplejump.github.io/stargate/] also uses the 
 Stratio's open source JSON syntax:
 {code}
 SELECT name,company FROM PERSON WHERE stargate ='{
 filter: {
 type: range,
 field: company,
 lower: a,
 upper: p
 },
 sort:{
fields: [{field:name,reverse:true}]
 }
 }';
 {code}
 These syntaxes are validated by the corresponding 2i implementation. This 
 validation is done behind the StorageProxy command distribution. So, far as I 
 know, there is no way to give rich feedback about syntax errors to CQL users.
 I'm uploading a patch with some changes trying to improve this. I propose 
 adding an empty validation method to SecondaryIndexSearcher that can be 
 overridden by custom 2i implementations:
 {code}
 public void validate(ListIndexExpression clause) {}
 {code}
 And call it from SelectStatement#getRangeCommand:
 {code}
 ColumnFamilyStore cfs = 
 Keyspace.open(keyspace()).getColumnFamilyStore(columnFamily());
 for (SecondaryIndexSearcher searcher : 
 cfs.indexManager.getIndexSearchersForQuery(expressions))
 {
 try
 {
 searcher.validate(expressions);
 }
 catch (RuntimeException e)
 {
 String exceptionMessage = e.getMessage();
 if (exceptionMessage != null 
  !exceptionMessage.trim().isEmpty())
 throw new InvalidRequestException(
 Invalid index expression:  + e.getMessage());
 else
 throw new InvalidRequestException(
 Invalid index expression);
 }
 }
 {code}
 In this way C* allows custom 2i implementations to give feedback about syntax 
 errors.
 We are currently using these changes in a fork with no problems.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7642) Adaptive Consistency

2014-07-31 Thread Rustam Aliyev (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080774#comment-14080774
]

Rustam Aliyev commented on CASSANDRA-7642:
--

Ah, I see what you mean. In case with 2 DCs, it will work (assuming it will
fail when CL drops below LOCAL_Q).

However, for DC number 2, it would suffer most of the points discussed in the
Criticism section of this ticket - no CL contract (app may not be able to
handle certain CL levels), unpredictable, transparent and silent downgrading,
etc.

Adaptive Consistency

Key: CASSANDRA-7642
URL: https://issues.apache.org/jira/browse/CASSANDRA-7642
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Rustam Aliyev
Fix For: 3.0

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7655) Slow repair on empty cluster

2014-07-31 Thread Jens Rantil (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080772#comment-14080772
 ] 

Jens Rantil commented on CASSANDRA-7655:


Oh, yeah:
{noformat}
cqlsh DESC KEYSPACES;

system  my-keyspace  dse_system  system_auth  system_traces
{noformat}

 Slow repair on empty cluster
 

 Key: CASSANDRA-7655
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7655
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jens Rantil
Priority: Minor
  Labels: repair

 Background: I have done:
  * I've set up three (Datastax DSE) nodes with replication factor of 3. Each 
 node has 256 vnodes. Each is running Cassandra 2.0.8.39, according to `cqlsh`.
  * [enabled 
 authorization|http://www.datastax.com/documentation/cassandra/1.2/cassandra/security/secure_config_native_authorize_t.html]
  * [enabled 
 authentication|http://www.datastax.com/documentation/cassandra/1.2/cassandra/security/secure_about_native_authenticate_c.html]
  * created a custom keyspace with replication factor and created a smaller 
 table without putting any data into it.
 For fun execute a `nodetool repair` in my terminal this takes _23 minutes_. 
 This feels a bit slow to me for not having put _any_ data into my cluster. Is 
 this expected? Or a bug?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7575) Custom 2i validation

2014-07-31 Thread JIRA


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080783#comment-14080783
 ] 

Andrés de la Peña commented on CASSANDRA-7575:
--

[~sbtourist], here is the patch with the suggested changes. We have run some 
functional tests and it works fine. 

 Custom 2i validation
 

 Key: CASSANDRA-7575
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7575
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Reporter: Andrés de la Peña
Assignee: Andrés de la Peña
Priority: Minor
  Labels: 2i, cql3, secondaryIndex, secondary_index, select
 Fix For: 2.1.1

 Attachments: 2i_validation.patch, 2i_validation_v2.patch


 There are several projects using custom secondary indexes as an extension 
 point to integrate C* with other systems such as Solr or Lucene. The usual 
 approach is to embed third party indexing queries in CQL clauses. 
 For example, [DSE 
 Search|http://www.datastax.com/what-we-offer/products-services/datastax-enterprise]
  embeds Solr syntax this way:
 {code}
 SELECT title FROM solr WHERE solr_query='title:natio*';
 {code}
 [Stratio platform|https://github.com/Stratio/stratio-cassandra] embeds custom 
 JSON syntax for searching in Lucene indexes:
 {code}
 SELECT * FROM tweets WHERE lucene='{
 filter : {
 type: range,
 field: time,
 lower: 2014/04/25,
 upper: 2014/04/1
 },
 query  : {
 type: phrase, 
 field: body, 
 values: [big, data]
 },
 sort  : {fields: [ {field:time, reverse:true} ] }
 }';
 {code}
 Tuplejump [Stargate|http://tuplejump.github.io/stargate/] also uses the 
 Stratio's open source JSON syntax:
 {code}
 SELECT name,company FROM PERSON WHERE stargate ='{
 filter: {
 type: range,
 field: company,
 lower: a,
 upper: p
 },
 sort:{
fields: [{field:name,reverse:true}]
 }
 }';
 {code}
 These syntaxes are validated by the corresponding 2i implementation. This 
 validation is done behind the StorageProxy command distribution. So, far as I 
 know, there is no way to give rich feedback about syntax errors to CQL users.
 I'm uploading a patch with some changes trying to improve this. I propose 
 adding an empty validation method to SecondaryIndexSearcher that can be 
 overridden by custom 2i implementations:
 {code}
 public void validate(ListIndexExpression clause) {}
 {code}
 And call it from SelectStatement#getRangeCommand:
 {code}
 ColumnFamilyStore cfs = 
 Keyspace.open(keyspace()).getColumnFamilyStore(columnFamily());
 for (SecondaryIndexSearcher searcher : 
 cfs.indexManager.getIndexSearchersForQuery(expressions))
 {
 try
 {
 searcher.validate(expressions);
 }
 catch (RuntimeException e)
 {
 String exceptionMessage = e.getMessage();
 if (exceptionMessage != null 
  !exceptionMessage.trim().isEmpty())
 throw new InvalidRequestException(
 Invalid index expression:  + e.getMessage());
 else
 throw new InvalidRequestException(
 Invalid index expression);
 }
 }
 {code}
 In this way C* allows custom 2i implementations to give feedback about syntax 
 errors.
 We are currently using these changes in a fork with no problems.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7654) CQL INSERT improvement


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080788#comment-14080788
 ] 

Aleksey Yeschenko commented on CASSANDRA-7654:
--

I can swear there is already a ticket for this, so it's a duplicate.

Ultimately this is merely a convenience syntax - you can get the same exact 
result w/ batches (almost with the same level of overhead, if using prepared 
statements + native protocol batches).

We don't mind adding it to CQL, it's just a very low-priority issue considering 
that you can get the same result in a different way.

 CQL INSERT improvement
 --

 Key: CASSANDRA-7654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7654
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Stupp

 It would be nice to be able to add multiple rows using a single {{INSERT}}.
 Restricted to the same partition.
 For example:
 Current behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 1, 41);
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 2, 42);
 {noformat}
 Wanted behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES
 ('foo', 1, 41),
 ('foo', 2, 42),
 ('foo', 3, 42),
 ('foo', 4, 42);
 {noformat}
 Assumed table def:
 {noformat}
 CREATE TABLE comp_key (
   key TEXT,
   clust   INT,
   num_val DECIMAL,
   PRIMARY KEY ( key, clust )
 );
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7656) UDT with null/missing attributes

2014-07-31 Thread Jaroslav Kamenik (JIRA)

Jaroslav Kamenik created CASSANDRA-7656:
---

 Summary: UDT with null/missing attributes 
 Key: CASSANDRA-7656
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7656
 Project: Cassandra
  Issue Type: Bug
Reporter: Jaroslav Kamenik


I have experienced problem with queriing UDTs stored with some not filled 
attributes through new java driver 2.1. I tried to query them in cqlsh too and 
it failed. I tried to simulate it again with fresh C* directly in cqlsh and it 
seems it has problems in some cases. I have tested it with UDT defined as (a 
ascii, b ascii, c ascii, d ascii, e ascii, f ascii, g ascii). 

Few observations:

{noformat}
Store {a:'a'} is ok, it returns {a: 'a', b: '', c: '', d: '', e: '', f: '', g: 
''}
Store {a:'a', b:'b', c:'c', d:'d', e:'e', f:'f', g:'g'} is ok, returns all 
filled.
Store {a:'a',  g:'g'} fills a only.
Store {a:'a', b:'b', d:'d', e:'e', f:'f', g:'g'} (missing c) failed on load.
Store {a:'a', f:'f', g:'g'} fills just a. 
Store {f:'f',g:'g'} nothing filled
Store {e:'e',f:'f',g:'g'} failed on load.

{noformat}

you can reproduce it with:

{noformat}
./cqlsh
Connected to WOC at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.1.0-rc4 | CQL spec 3.2.0 | Native protocol v3]
Use HELP for help.
cqlsh create keyspace testks WITH REPLICATION = { 'class' : 'SimpleStrategy', 
'replication_factor' : 1};
cqlsh use testks;
cqlsh:testks CREATE TYPE IF NOT EXISTS data (a ascii, b ascii, c ascii, d 
ascii, e ascii, f ascii, g ascii);
cqlsh:testks CREATE TABLE IF NOT EXISTS bbb (a ascii primary key, b data);
cqlsh:testks insert into testks.bbb (a,b) values ('a', {a:'a'});
cqlsh:testks select * from bbb;

 a | b
---+
 a | {a: 'a', b: '', c: '', d: '', e: '', f: '', g: ''}

(1 rows)

cqlsh:testks insert into testks.bbb (a,b) values ('a', {a:'a', b:'b', c:'c', 
d:'d', e:'e', f:'f', g:'g'});
cqlsh:testks select * from bbb;

 a | b
---+--
 a | {a: 'a', b: 'b', c: 'c', d: 'd', e: 'e', f: 'f', g: 'g'}

(1 rows)

cqlsh insert into testks.bbb (a,b) values ('a', {a:'a',  g:'g'});
cqlsh select * from testks.bbb;

 a | b
---+
 a | {a: 'a', b: '', c: '', d: '', e: '', f: '', g: ''}

(1 rows)

cqlsh:testks insert into testks.bbb (a,b) values ('a', {a:'a', b:'b', d:'d', 
e:'e', f:'f', g:'g'});
cqlsh:testks select * from bbb;
Traceback (most recent call last):
  File ./cqlsh, line 901, in perform_simple_statement
rows = self.session.execute(statement, trace=self.tracing_enabled)
  File 
/srv/apache-cassandra-2.1.0-rc4/bin/../lib/cassandra-driver-internal-only-2.1.0b1.post.zip/cassandra-driver-2.1.0b1.post/cassandra/cluster.py,
 line 1186, in execute
result = future.result(timeout)
  File 
/srv/apache-cassandra-2.1.0-rc4/bin/../lib/cassandra-driver-internal-only-2.1.0b1.post.zip/cassandra-driver-2.1.0b1.post/cassandra/cluster.py,
 line 2610, in result
raise self._final_exception
error: unpack requires a string argument of length 4
{noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6276) CQL: Map can not be created with the same name as a previously dropped list


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080816#comment-14080816
 ] 

Aleksey Yeschenko commented on CASSANDRA-6276:
--

Unfortunately, we can't allow dropping a component from the comparator, 
including dropping individual collection columns from ColumnToCollectionType.

If we do allow that, and have pre-existing data of that type, C* simply 
wouldn't know how to compare those:

{code:title=ColumnToCollectionType.java}
public int compareCollectionMembers(ByteBuffer o1, ByteBuffer o2, 
ByteBuffer collectionName)
{
CollectionType t = defined.get(collectionName);
if (t == null)
throw new 
RuntimeException(ByteBufferUtil.bytesToHex(collectionName) +  is not defined 
as a collection);

return t.nameComparator().compare(o1, o2);
}
{code}

A simple algorithm to hit the RTE:
1. create table test (id int primary key, col1 mapint, int, col2 setint);
2. insert into test (id, col1, col2) VALUES ( 0, \{0:0, 1:1\}, \{0,1\});
3. flush
4. update test set col1 = col1 + \{2:2\}, col2 = col2 + \{2\} where id = 0;
5. flush
6. select * from test;

{noformat}
java.lang.RuntimeException: 636f6c31 is not defined as a collection
at 
org.apache.cassandra.db.marshal.ColumnToCollectionType.compareCollectionMembers(ColumnToCollectionType.java:79)
 ~[main/:na]
at 
org.apache.cassandra.db.composites.CompoundSparseCellNameType$WithCollection.compare(CompoundSparseCellNameType.java:296)
 ~[main/:na]
at 
org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:61)
 ~[main/:na]
at 
org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:58)
 ~[main/:na]
at 
org.apache.cassandra.utils.MergeIterator$Candidate.compareTo(MergeIterator.java:154)
 ~[main/:na]
at 
org.apache.cassandra.utils.MergeIterator$Candidate.compareTo(MergeIterator.java:131)
 ~[main/:na]
{noformat}

For this reason alone we can't allow getting rid of a comparator component.

However, even if we did, and allowed to create a different collection with the 
same name, we'd hit a different issue: the new collection's comparator would be 
used to compare potentially incompatible types. Now, your unit tests aren't 
failing b/c most of our comparators assume valid values and don't perform extra 
validation, then use something like ByteBufferUtil.compareUnsigned() to compare 
the values, which doesn't fail and will just stop once the shortest BB gets 
exhausted. One exception is tuples/usertypes - they *do* expect at least length 
to be there, and will throw an exception.

Example:
1. create table test (id int primary key, col setboolean);
2. insert into test (id, col) values (0, \{true,false\});
3. alter table test drop col;
4. create type test (f1 int);
5. alter table test add col settest;
6. update test set col = col + \{ \{f1 : 0 \} \} where id = 0;
7. select * from test;

{noformat}
java.nio.BufferUnderflowException: null
at java.nio.Buffer.nextGetIndex(Buffer.java:498) ~[na:1.7.0_65]
at java.nio.HeapByteBuffer.getInt(HeapByteBuffer.java:355) 
~[na:1.7.0_65]
at org.apache.cassandra.db.marshal.TupleType.compare(TupleType.java:80) 
~[main/:na]
at org.apache.cassandra.db.marshal.TupleType.compare(TupleType.java:38) 
~[main/:na]
at 
org.apache.cassandra.db.marshal.ColumnToCollectionType.compareCollectionMembers(ColumnToCollectionType.java:81)
 ~[main/:na]
at 
org.apache.cassandra.db.composites.CompoundSparseCellNameType$WithCollection.compare(CompoundSparseCellNameType.java:296)
 ~[main/:na]
at 
org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:61)
 ~[main/:na]
at 
org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:58)
 ~[main/:na]
at 
org.apache.cassandra.utils.MergeIterator$Candidate.compareTo(MergeIterator.java:154)
 ~[main/:na]
{noformat}

 CQL: Map can not be created with the same name as a previously dropped list
 ---

 Key: CASSANDRA-6276
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6276
 Project: Cassandra
  Issue Type: Bug
 Environment:  Cassandra 2.0.2 | CQL spec 3.1.0
 centos 64 bit
 Java(TM) SE Runtime Environment (build 1.7.0-b147)
Reporter: Oli Schacher
Assignee: Benjamin Lerer
Priority: Minor
  Labels: cql
 Fix For: 2.1.1

 Attachments: CASSANDRA-6276.txt


 If create a list, drop it and create a map with the same name, i get Bad 
 Request: comparators do not match or are not compatible.
 {quote}
 cqlsh:os_test1 create table thetable(id timeuuid primary key, somevalue 
 text);
 cqlsh:os_test1

[jira] [Updated] (CASSANDRA-7593) Errors when upgrading through several versions to 2.1


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-7593:
---

Attachment: 0001-keep-clusteringSize-in-CompoundComposite.patch

 Errors when upgrading through several versions to 2.1
 -

 Key: CASSANDRA-7593
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7593
 Project: Cassandra
  Issue Type: Bug
 Environment: java 1.7
Reporter: Russ Hatch
Assignee: Tyler Hobbs
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-keep-clusteringSize-in-CompoundComposite.patch, 
 7593.txt


 I'm seeing two different errors cropping up in the dtest which upgrades a 
 cluster through several versions.
 This is the more common error:
 {noformat}
 ERROR [GossipStage:10] 2014-07-22 13:14:30,028 CassandraDaemon.java:168 - 
 Exception in thread Thread[GossipStage:10,5,main]
 java.lang.AssertionError: null
 at 
 org.apache.cassandra.db.filter.SliceQueryFilter.shouldInclude(SliceQueryFilter.java:347)
  ~[main/:na]
 at 
 org.apache.cassandra.db.filter.QueryFilter.shouldInclude(QueryFilter.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
  ~[main/:na]
 at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:345) 
 ~[main/:na]
 at 
 org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:293)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:302)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:263)
  ~[main/:na]
 at 
 org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:514)
  ~[main/:na]
 at 
 org.apache.cassandra.net.OutboundTcpConnectionPool.init(OutboundTcpConnectionPool.java:51)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:522)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:536)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:689)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:663)
  ~[main/:na]
 at 
 org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40) 
 ~[main/:na]
 at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
 ~[main/:na]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  ~[na:1.7.0_60]
 at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
 {noformat}
 The same test sometimes fails with this exception instead:
 {noformat}
 ERROR [CompactionExecutor:4] 2014-07-22 16:18:21,008 CassandraDaemon.java:168 
 - Exception in thread Thread[CompactionExecutor:4,1,RMI Runtime]
 java.util.concurrent.RejectedExecutionException: Task 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@7059d3e9 
 rejected from 
 org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor@108f1504[Terminated,
  pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 95]
 at 
 java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) 
 ~[na:1.7.0_60]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619)
  ~[na:1.7.0_60]
 at 
 org.apache.cassandra.io.sstable.SSTableReader.scheduleTidy(SSTableReader.java:628)
  ~[main/:na]
 at

[jira] [Commented] (CASSANDRA-7593) Errors when upgrading through several versions to 2.1


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080817#comment-14080817
 ] 

Marcus Eriksson commented on CASSANDRA-7593:


Still not working, we get clusteringSize() = 1 for rt.max and clusteringSize() 
= 0 for min

when deserializing the RT we get to CSCNT.WithCollection.makeWith():
{code}
protected Composite makeWith(ByteBuffer[] components, int size, 
Composite.EOC eoc, boolean isStatic)
{
if (size  clusteringSize + 1 || eoc != Composite.EOC.NONE)
return new CompoundComposite(components, size, 
isStatic).withEOC(eoc);

return new CompoundSparseCellName(components, clusteringSize, 
idFor(components[clusteringSize]), isStatic);
}
{code}
so, if we have an EOC we wrap a CompoundComposite with size (which is 1 in this 
case), and if we don't, we create a CSCN with clusteringSize (which is 0)

Attaching a patch that keeps clusteringSize in the compound composite, but have 
to say that I don't know enough about this to say if it breaks everything else.

a way to repro:

# start cassandra2.0
# CREATE TABLE t (k int PRIMARY KEY,something text, a setvarchar, b 
setvarchar);
# update t set b = null where k = 1;
# flush
# upgrade to 2.1
# upgradesstables
# check minmax column names (i hacked SSTableMetadataViewer to dump the 
contents)



 Errors when upgrading through several versions to 2.1
 -

 Key: CASSANDRA-7593
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7593
 Project: Cassandra
  Issue Type: Bug
 Environment: java 1.7
Reporter: Russ Hatch
Assignee: Tyler Hobbs
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-keep-clusteringSize-in-CompoundComposite.patch, 
 7593.txt


 I'm seeing two different errors cropping up in the dtest which upgrades a 
 cluster through several versions.
 This is the more common error:
 {noformat}
 ERROR [GossipStage:10] 2014-07-22 13:14:30,028 CassandraDaemon.java:168 - 
 Exception in thread Thread[GossipStage:10,5,main]
 java.lang.AssertionError: null
 at 
 org.apache.cassandra.db.filter.SliceQueryFilter.shouldInclude(SliceQueryFilter.java:347)
  ~[main/:na]
 at 
 org.apache.cassandra.db.filter.QueryFilter.shouldInclude(QueryFilter.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
  ~[main/:na]
 at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:345) 
 ~[main/:na]
 at 
 org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:293)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:302)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:263)
  ~[main/:na]
 at 
 org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:514)
  ~[main/:na]
 at 
 org.apache.cassandra.net.OutboundTcpConnectionPool.init(OutboundTcpConnectionPool.java:51)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:522)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:536)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:689)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:663)
  ~[main/:na]
 at 
 org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40) 
 ~[main/:na]
 at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
 ~[main/:na]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  ~[na:1.7.0_60]
 at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
 {noformat}
 The same test sometimes fails with this exception instead:
 {noformat}
 ERROR [CompactionExecutor:4] 2014-07-22 16:18:21,008 CassandraDaemon.java:168 
 - Exception in thread

[jira] [Comment Edited] (CASSANDRA-7593) Errors when upgrading through several versions to 2.1


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080817#comment-14080817
 ] 

Marcus Eriksson edited comment on CASSANDRA-7593 at 7/31/14 12:56 PM:
--

Still not working, we get clusteringSize() = 1 for rt.max and clusteringSize() 
= 0 for min

when deserializing the RT we get to CSCNT.WithCollection.makeWith():
{code}
protected Composite makeWith(ByteBuffer[] components, int size, 
Composite.EOC eoc, boolean isStatic)
{
if (size  clusteringSize + 1 || eoc != Composite.EOC.NONE)
return new CompoundComposite(components, size, 
isStatic).withEOC(eoc);

return new CompoundSparseCellName(components, clusteringSize, 
idFor(components[clusteringSize]), isStatic);
}
{code}
so, if we have an EOC we wrap a CompoundComposite with size (which is 1 in this 
case), and if we don't, we create a CSCN with clusteringSize (which is 0)

Attaching a patch that keeps clusteringSize in the compound composite, but have 
to say that I don't know enough about this to say if it breaks everything else. 
It applies on top of the other patch.

a way to repro:

# start cassandra2.0
# CREATE TABLE t (k int PRIMARY KEY,something text, a setvarchar, b 
setvarchar);
# update t set b = null where k = 1;
# flush
# upgrade to 2.1
# upgradesstables
# check minmax column names (i hacked SSTableMetadataViewer to dump the 
contents)




was (Author: krummas):
Still not working, we get clusteringSize() = 1 for rt.max and clusteringSize() 
= 0 for min

when deserializing the RT we get to CSCNT.WithCollection.makeWith():
{code}
protected Composite makeWith(ByteBuffer[] components, int size, 
Composite.EOC eoc, boolean isStatic)
{
if (size  clusteringSize + 1 || eoc != Composite.EOC.NONE)
return new CompoundComposite(components, size, 
isStatic).withEOC(eoc);

return new CompoundSparseCellName(components, clusteringSize, 
idFor(components[clusteringSize]), isStatic);
}
{code}
so, if we have an EOC we wrap a CompoundComposite with size (which is 1 in this 
case), and if we don't, we create a CSCN with clusteringSize (which is 0)

Attaching a patch that keeps clusteringSize in the compound composite, but have 
to say that I don't know enough about this to say if it breaks everything else.

a way to repro:

# start cassandra2.0
# CREATE TABLE t (k int PRIMARY KEY,something text, a setvarchar, b 
setvarchar);
# update t set b = null where k = 1;
# flush
# upgrade to 2.1
# upgradesstables
# check minmax column names (i hacked SSTableMetadataViewer to dump the 
contents)



 Errors when upgrading through several versions to 2.1
 -

 Key: CASSANDRA-7593
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7593
 Project: Cassandra
  Issue Type: Bug
 Environment: java 1.7
Reporter: Russ Hatch
Assignee: Tyler Hobbs
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-keep-clusteringSize-in-CompoundComposite.patch, 
 7593.txt


 I'm seeing two different errors cropping up in the dtest which upgrades a 
 cluster through several versions.
 This is the more common error:
 {noformat}
 ERROR [GossipStage:10] 2014-07-22 13:14:30,028 CassandraDaemon.java:168 - 
 Exception in thread Thread[GossipStage:10,5,main]
 java.lang.AssertionError: null
 at 
 org.apache.cassandra.db.filter.SliceQueryFilter.shouldInclude(SliceQueryFilter.java:347)
  ~[main/:na]
 at 
 org.apache.cassandra.db.filter.QueryFilter.shouldInclude(QueryFilter.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
  ~[main/:na]
 at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:345) 
 ~[main/:na]
 at 
 org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:293)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:302)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:263)
  ~[main/:na]
 at

[jira] [Resolved] (CASSANDRA-6229) transfers never occur after enabling a shuffle

[
https://issues.apache.org/jira/browse/CASSANDRA-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aleksey Yeschenko resolved CASSANDRA-6229.
--

Resolution: Not a Problem
Reproduced In: 2.0.1, 1.2.11 (was: 1.2.11, 2.0.1)

Not a problem since CASSANDRA-7601.

transfers never occur after enabling a shuffle
--

Key: CASSANDRA-6229
URL: https://issues.apache.org/jira/browse/CASSANDRA-6229
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Daniel Meyer
Assignee: Joshua McKenzie

Using the following documentation as reference:
http://www.datastax.com/documentation/cassandra/2.0/webhelp/cassandra/tools/toolsCassandraShuffle.html
After running the 'shuffle en' step, the command does not block giving the
indication that a transfer has occurred. However, running 'shuffle ls' at an
arbitrary time after enabling the shuffle results in a large list of pending
transfers. From the users perspective it is unclear what is happening;
however, it looks like the transfer does not actually occur.
repro steps:
1) cd to latest cassandra-2.0 branch
2) ccm create shuffle_test
3 ccm populate -n 3
4) delete the 'num_tokens' line from each cassandra.yaml file for all three
nodes.
5) ccm start
6) run 'ccm node1 ring' and verify the vnodes are not enabled.
7) ccm node1 stress -o insert
8) for each node set 'num_tokens: 256' in the cassandra.yaml
9) restart the nodes
10) run 'ccm node1 ring' to verify vnodes is enabled
11) ccm node1 shuffle create
12) ccm node1 shuffle en
13) wait arbitrary amount of time and run 'ccm node1 shuffle ls'.
Expected: transfers should eventually happen and not be observed with
'shuffle ls'
Actual: transfers never seem to occur. If in fact they do occur it is not
obvious.
If transfers do in fact occur it is very difficult to tell. This was
initially discovered on a real cluster and the cluster sat overnight without
any transfers happening. As a user I would also expect 'shuffle en' to
block. The non blocking behavior does not seem ideal from a user perspective.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7593) Errors when upgrading through several versions to 2.1


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080825#comment-14080825
 ] 

Benedict commented on CASSANDRA-7593:
-

Might be better to just expose this in CSCNT, since we have access to it when 
doing this.

 Errors when upgrading through several versions to 2.1
 -

 Key: CASSANDRA-7593
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7593
 Project: Cassandra
  Issue Type: Bug
 Environment: java 1.7
Reporter: Russ Hatch
Assignee: Tyler Hobbs
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-keep-clusteringSize-in-CompoundComposite.patch, 
 7593.txt


 I'm seeing two different errors cropping up in the dtest which upgrades a 
 cluster through several versions.
 This is the more common error:
 {noformat}
 ERROR [GossipStage:10] 2014-07-22 13:14:30,028 CassandraDaemon.java:168 - 
 Exception in thread Thread[GossipStage:10,5,main]
 java.lang.AssertionError: null
 at 
 org.apache.cassandra.db.filter.SliceQueryFilter.shouldInclude(SliceQueryFilter.java:347)
  ~[main/:na]
 at 
 org.apache.cassandra.db.filter.QueryFilter.shouldInclude(QueryFilter.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
  ~[main/:na]
 at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:345) 
 ~[main/:na]
 at 
 org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:293)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:302)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:263)
  ~[main/:na]
 at 
 org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:514)
  ~[main/:na]
 at 
 org.apache.cassandra.net.OutboundTcpConnectionPool.init(OutboundTcpConnectionPool.java:51)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:522)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:536)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:689)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:663)
  ~[main/:na]
 at 
 org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40) 
 ~[main/:na]
 at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
 ~[main/:na]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  ~[na:1.7.0_60]
 at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
 {noformat}
 The same test sometimes fails with this exception instead:
 {noformat}
 ERROR [CompactionExecutor:4] 2014-07-22 16:18:21,008 CassandraDaemon.java:168 
 - Exception in thread Thread[CompactionExecutor:4,1,RMI Runtime]
 java.util.concurrent.RejectedExecutionException: Task 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@7059d3e9 
 rejected from 
 org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor@108f1504[Terminated,
  pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 95]
 at 
 java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) 
 ~[na:1.7.0_60]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619)
  ~[na:1.7.0_60]
 at 
 org.apache.cassandra.io.sstable.SSTableReader.scheduleTidy(SSTableReader.java:628)

[jira] [Commented] (CASSANDRA-7654) CQL INSERT improvement

2014-07-31 Thread T Jake Luciani (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080830#comment-14080830
 ] 

T Jake Luciani commented on CASSANDRA-7654:
---

You can already accomplish this using a prepared statement, which should be the 
only way we support this IMO.

http://www.datastax.com/dev/blog/client-side-improvements-in-cassandra-2-0

 CQL INSERT improvement
 --

 Key: CASSANDRA-7654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7654
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Stupp

 It would be nice to be able to add multiple rows using a single {{INSERT}}.
 Restricted to the same partition.
 For example:
 Current behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 1, 41);
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 2, 42);
 {noformat}
 Wanted behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES
 ('foo', 1, 41),
 ('foo', 2, 42),
 ('foo', 3, 42),
 ('foo', 4, 42);
 {noformat}
 Assumed table def:
 {noformat}
 CREATE TABLE comp_key (
   key TEXT,
   clust   INT,
   num_val DECIMAL,
   PRIMARY KEY ( key, clust )
 );
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7654) CQL INSERT improvement


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080833#comment-14080833
 ] 

Aleksey Yeschenko commented on CASSANDRA-7654:
--

[~tjake] it's nice and convenient for cqlsh, but that's about it. Which is why 
it's such a low-priority ticket and won't happen any time soon, if ever.

 CQL INSERT improvement
 --

 Key: CASSANDRA-7654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7654
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Stupp

 It would be nice to be able to add multiple rows using a single {{INSERT}}.
 Restricted to the same partition.
 For example:
 Current behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 1, 41);
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 2, 42);
 {noformat}
 Wanted behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES
 ('foo', 1, 41),
 ('foo', 2, 42),
 ('foo', 3, 42),
 ('foo', 4, 42);
 {noformat}
 Assumed table def:
 {noformat}
 CREATE TABLE comp_key (
   key TEXT,
   clust   INT,
   num_val DECIMAL,
   PRIMARY KEY ( key, clust )
 );
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7654) CQL INSERT improvement


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080834#comment-14080834
 ] 

Robert Stupp commented on CASSANDRA-7654:
-

I could not find a ticket for this (searched for unresolved tickets with 
'insert' and 'multiple') :(

Yea - it is a convenience syntax for a rare situation, which can of course be 
achieved with pstmt-batches (unlogged should work in this case, I think).


 CQL INSERT improvement
 --

 Key: CASSANDRA-7654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7654
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Stupp

 It would be nice to be able to add multiple rows using a single {{INSERT}}.
 Restricted to the same partition.
 For example:
 Current behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 1, 41);
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 2, 42);
 {noformat}
 Wanted behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES
 ('foo', 1, 41),
 ('foo', 2, 42),
 ('foo', 3, 42),
 ('foo', 4, 42);
 {noformat}
 Assumed table def:
 {noformat}
 CREATE TABLE comp_key (
   key TEXT,
   clust   INT,
   num_val DECIMAL,
   PRIMARY KEY ( key, clust )
 );
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7654) CQL INSERT improvement


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-7654:


Priority: Minor  (was: Major)

 CQL INSERT improvement
 --

 Key: CASSANDRA-7654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7654
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Stupp
Priority: Minor

 It would be nice to be able to add multiple rows using a single {{INSERT}}.
 Restricted to the same partition.
 For example:
 Current behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 1, 41);
 INSERT INTO comp_key (key, num_val)
   VALUES ('foo', 2, 42);
 {noformat}
 Wanted behaviour:
 {noformat}
 INSERT INTO comp_key (key, num_val)
   VALUES
 ('foo', 1, 41),
 ('foo', 2, 42),
 ('foo', 3, 42),
 ('foo', 4, 42);
 {noformat}
 Assumed table def:
 {noformat}
 CREATE TABLE comp_key (
   key TEXT,
   clust   INT,
   num_val DECIMAL,
   PRIMARY KEY ( key, clust )
 );
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6599) CQL updates should support column = column - { key1, key2, ... } syntax for removing map elements


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080869#comment-14080869
 ] 

Aleksey Yeschenko commented on CASSANDRA-6599:
--

After thinking about it for a while, I'm not sure I like accepting set literals 
for map operations.

I personally would prefer allowing nulls as values in map literals, so that you 
could do something like this instead, without inventing new syntax:

{code}
update table set map = map + {'key1': null, 'key2': null} where ...
{code}

I believe this already works with prepared statements, as is, but could be 
wrong.

 CQL updates should support column = column - { key1, key2, ... } syntax for 
 removing map elements
 ---

 Key: CASSANDRA-6599
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6599
 Project: Cassandra
  Issue Type: Wish
Reporter: Gavin
Assignee: Benjamin Lerer
Priority: Minor
  Labels: cql
 Fix For: 2.1.1

 Attachments: CASSANDRA-6599.txt


 A variable number number of elements can be removed from lists and sets using 
 an update statement of the form update  set column=column - {} where 
   This syntax should also be supported for map columns.  This would be 
 especially useful for prepared statements (I know that you can use set 
 column[...] = null to remove items in an update statement, but that only 
 works for one element at a time).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[Cassandra Wiki] Update of ContributorsGroup by BrandonWilliams

2014-07-31 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The ContributorsGroup page has been changed by BrandonWilliams:
https://wiki.apache.org/cassandra/ContributorsGroup?action=diffrev1=32rev2=33

   * PhiloYang
   * Changjiu
   * woolfel
+  * MichaelShuler

[jira] [Updated] (CASSANDRA-7636) Data is not filtered out when using WHERE clause on cluster column on Column Family with row cache on.


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-7636:
-

Reviewer: Aleksey Yeschenko

 Data is not filtered out when using WHERE clause on cluster column on Column 
 Family with row cache on.
 --

 Key: CASSANDRA-7636
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7636
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.1.0-rc4
Reporter: Krzysztof Zarzycki
Assignee: Marcus Eriksson
 Fix For: 2.1.0

 Attachments: 0001-actually-filter-the-cached-result.patch


 My pretty simplified case looks like the following:
 I create a table with partition and cluster column. I set key caching to NONE 
 and row caching to ALL.  
 When I'm running some SELECTs with WHERE clause filtering on cluster columns, 
 the rows sometimes are not getting filtered out. When? Probably when the row 
 gets loaded to row cache (By some previous query).
 Look at this scenario: 
 {code}
 cqlsh:xxx create KEYSPACE test_keyspace WITH replication = {'class': 
 'SimpleStrategy', 'replication_factor': 1};
 cqlsh:xxx use test_keyspace ;
 cqlsh:test_keyspace CREATE TABLE test (p1 bigint, c1 int, PRIMARY KEY (p1, 
 c1) )  WITH caching = '{keys:NONE, rows_per_partition:ALL}';
 cqlsh:test_keyspace insert into test (p1, c1 ) values ( 123, 10);
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
 (0 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  9;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 {code}
 Running the same scenario, but with row cache turned OFF works fine. 
 The filtering on other (partition) columns runs fine. Only the clustering 
 column is somewhat malfunctioning. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7636) Data is not filtered out when using WHERE clause on cluster column on Column Family with row cache on.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080947#comment-14080947
 ] 

Aleksey Yeschenko commented on CASSANDRA-7636:
--

LGTM, +1

 Data is not filtered out when using WHERE clause on cluster column on Column 
 Family with row cache on.
 --

 Key: CASSANDRA-7636
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7636
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.1.0-rc4
Reporter: Krzysztof Zarzycki
Assignee: Marcus Eriksson
 Fix For: 2.1.0

 Attachments: 0001-actually-filter-the-cached-result.patch


 My pretty simplified case looks like the following:
 I create a table with partition and cluster column. I set key caching to NONE 
 and row caching to ALL.  
 When I'm running some SELECTs with WHERE clause filtering on cluster columns, 
 the rows sometimes are not getting filtered out. When? Probably when the row 
 gets loaded to row cache (By some previous query).
 Look at this scenario: 
 {code}
 cqlsh:xxx create KEYSPACE test_keyspace WITH replication = {'class': 
 'SimpleStrategy', 'replication_factor': 1};
 cqlsh:xxx use test_keyspace ;
 cqlsh:test_keyspace CREATE TABLE test (p1 bigint, c1 int, PRIMARY KEY (p1, 
 c1) )  WITH caching = '{keys:NONE, rows_per_partition:ALL}';
 cqlsh:test_keyspace insert into test (p1, c1 ) values ( 123, 10);
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
 (0 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  9;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 cqlsh:test_keyspace select * from test where p1 = 123 and c1  10;
  p1  | c1
 -+
  123 | 10
 (1 rows)
 {code}
 Running the same scenario, but with row cache turned OFF works fine. 
 The filtering on other (partition) columns runs fine. Only the clustering 
 column is somewhat malfunctioning. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CASSANDRA-7655) Slow repair on empty cluster


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams resolved CASSANDRA-7655.
-

Resolution: Duplicate

 Slow repair on empty cluster
 

 Key: CASSANDRA-7655
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7655
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jens Rantil
Priority: Minor
  Labels: repair

 Background: I have done:
  * I've set up three (Datastax DSE) nodes with replication factor of 3. Each 
 node has 256 vnodes. Each is running Cassandra 2.0.8.39, according to `cqlsh`.
  * [enabled 
 authorization|http://www.datastax.com/documentation/cassandra/1.2/cassandra/security/secure_config_native_authorize_t.html]
  * [enabled 
 authentication|http://www.datastax.com/documentation/cassandra/1.2/cassandra/security/secure_about_native_authenticate_c.html]
  * created a custom keyspace with replication factor and created a smaller 
 table without putting any data into it.
 For fun execute a `nodetool repair` in my terminal this takes _23 minutes_. 
 This feels a bit slow to me for not having put _any_ data into my cluster. Is 
 this expected? Or a bug?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7656) UDT with null/missing attributes


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-7656:
--

  Component/s: Core
   API
 Priority: Minor  (was: Major)
Fix Version/s: 2.1.0
 Assignee: Tyler Hobbs

 UDT with null/missing attributes 
 -

 Key: CASSANDRA-7656
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7656
 Project: Cassandra
  Issue Type: Bug
  Components: API, Core
Reporter: Jaroslav Kamenik
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 2.1.0


 I have experienced problem with queriing UDTs stored with some not filled 
 attributes through new java driver 2.1. I tried to query them in cqlsh too 
 and it failed. I tried to simulate it again with fresh C* directly in cqlsh 
 and it seems it has problems in some cases. I have tested it with UDT defined 
 as (a ascii, b ascii, c ascii, d ascii, e ascii, f ascii, g ascii). 
 Few observations:
 {noformat}
 Store {a:'a'} is ok, it returns {a: 'a', b: '', c: '', d: '', e: '', f: '', 
 g: ''}
 Store {a:'a', b:'b', c:'c', d:'d', e:'e', f:'f', g:'g'} is ok, returns all 
 filled.
 Store {a:'a',  g:'g'} fills a only.
 Store {a:'a', b:'b', d:'d', e:'e', f:'f', g:'g'} (missing c) failed on load.
 Store {a:'a', f:'f', g:'g'} fills just a. 
 Store {f:'f',g:'g'} nothing filled
 Store {e:'e',f:'f',g:'g'} failed on load.
 
 {noformat}
 you can reproduce it with:
 {noformat}
 ./cqlsh
 Connected to WOC at 127.0.0.1:9042.
 [cqlsh 5.0.1 | Cassandra 2.1.0-rc4 | CQL spec 3.2.0 | Native protocol v3]
 Use HELP for help.
 cqlsh create keyspace testks WITH REPLICATION = { 'class' : 
 'SimpleStrategy', 'replication_factor' : 1};
 cqlsh use testks;
 cqlsh:testks CREATE TYPE IF NOT EXISTS data (a ascii, b ascii, c ascii, d 
 ascii, e ascii, f ascii, g ascii);
 cqlsh:testks CREATE TABLE IF NOT EXISTS bbb (a ascii primary key, b data);
 cqlsh:testks insert into testks.bbb (a,b) values ('a', {a:'a'});
 cqlsh:testks select * from bbb;
  a | b
 ---+
  a | {a: 'a', b: '', c: '', d: '', e: '', f: '', g: ''}
 (1 rows)
 cqlsh:testks insert into testks.bbb (a,b) values ('a', {a:'a', b:'b', c:'c', 
 d:'d', e:'e', f:'f', g:'g'});
 cqlsh:testks select * from bbb;
  a | b
 ---+--
  a | {a: 'a', b: 'b', c: 'c', d: 'd', e: 'e', f: 'f', g: 'g'}
 (1 rows)
 cqlsh insert into testks.bbb (a,b) values ('a', {a:'a',  g:'g'});
 cqlsh select * from testks.bbb;
  a | b
 ---+
  a | {a: 'a', b: '', c: '', d: '', e: '', f: '', g: ''}
 (1 rows)
 cqlsh:testks insert into testks.bbb (a,b) values ('a', {a:'a', b:'b', d:'d', 
 e:'e', f:'f', g:'g'});
 cqlsh:testks select * from bbb;
 Traceback (most recent call last):
   File ./cqlsh, line 901, in perform_simple_statement
 rows = self.session.execute(statement, trace=self.tracing_enabled)
   File 
 /srv/apache-cassandra-2.1.0-rc4/bin/../lib/cassandra-driver-internal-only-2.1.0b1.post.zip/cassandra-driver-2.1.0b1.post/cassandra/cluster.py,
  line 1186, in execute
 result = future.result(timeout)
   File 
 /srv/apache-cassandra-2.1.0-rc4/bin/../lib/cassandra-driver-internal-only-2.1.0b1.post.zip/cassandra-driver-2.1.0b1.post/cassandra/cluster.py,
  line 2610, in result
 raise self._final_exception
 error: unpack requires a string argument of length 4
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7601) Data loss after nodetool taketoken


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-7601:


Attachment: 7601-1.2.txt

Probably a good idea to remove this from 1.2 as well since we have one more 1.2 
release in us.

 Data loss after nodetool taketoken
 --

 Key: CASSANDRA-7601
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7601
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tests
 Environment: Mac OSX Mavericks. Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Brandon Williams
Priority: Minor
  Labels: qa-resolved
 Fix For: 2.0.10, 2.1.0

 Attachments: 7601-1.2.txt, 7601-2.0.txt, 7601-2.1.txt, 
 consistent_bootstrap_test.py, taketoken.tar.gz


 The dtest 
 consistent_bootstrap_test.py:TestBootstrapConsistency.consistent_reads_after_relocate_test
  is failing on HEAD of the git branches 2.1 and 2.1.0.
 The test performs the following actions:
 - Create a cluster of 3 nodes
 - Create a keyspace with RF 2
 - Take node 3 down
 - Write 980 rows to node 2 with CL ONE
 - Flush node 2
 - Bring node 3 back up
 - Run nodetool taketoken on node 3 to transfer 80% of node 1's tokens to node 
 3
 - Check for data loss
 When the check for data loss is performed, only ~725 rows can be read via CL 
 ALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7651) Tolerate min/max column names of different lengths for slice intersections


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-7651:
-

Fix Version/s: 2.1.0

 Tolerate min/max column names of different lengths for slice intersections
 --

 Key: CASSANDRA-7651
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7651
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 2.1.0


 As determined in CASSANDRA-7593, we shouldn't depend on min and max column 
 names being the same length for SSTables.  (See {{ColumnSlice.intersects()}} 
 and {{SliceQueryFilter.shouldInclude()}}.)
 CASSANDRA-6237 depends on this.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6237) Allow range deletions in CQL


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080968#comment-14080968
 ] 

Aleksey Yeschenko commented on CASSANDRA-6237:
--

bq. p.s. I'm not sure that this should be part of this ticket. Should I fiil 
another one?

Your example would not delete a range - so a different ticket. There might be 
one open already.

 Allow range deletions in CQL
 

 Key: CASSANDRA-6237
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6237
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Benjamin Lerer
Priority: Minor
  Labels: cql
 Fix For: 2.1.1


 We uses RangeTombstones internally in a number of places, but we could expose 
 more directly too. Typically, given a table like:
 {noformat}
 CREATE TABLE events (
 id text,
 created_at timestamp,
 content text,
 PRIMARY KEY (id, created_at)
 )
 {noformat}
 we could allow queries like:
 {noformat}
 DELETE FROM events WHERE id='someEvent' AND created_at  'Jan 3, 2013';
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7601) Data loss after nodetool taketoken


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-7601:


Attachment: 7601-1.2.txt

 Data loss after nodetool taketoken
 --

 Key: CASSANDRA-7601
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7601
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tests
 Environment: Mac OSX Mavericks. Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Brandon Williams
Priority: Minor
  Labels: qa-resolved
 Fix For: 2.0.10, 2.1.0

 Attachments: 7601-1.2.txt, 7601-2.0.txt, 7601-2.1.txt, 
 consistent_bootstrap_test.py, taketoken.tar.gz


 The dtest 
 consistent_bootstrap_test.py:TestBootstrapConsistency.consistent_reads_after_relocate_test
  is failing on HEAD of the git branches 2.1 and 2.1.0.
 The test performs the following actions:
 - Create a cluster of 3 nodes
 - Create a keyspace with RF 2
 - Take node 3 down
 - Write 980 rows to node 2 with CL ONE
 - Flush node 2
 - Bring node 3 back up
 - Run nodetool taketoken on node 3 to transfer 80% of node 1's tokens to node 
 3
 - Check for data loss
 When the check for data loss is performed, only ~725 rows can be read via CL 
 ALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Reopened] (CASSANDRA-7601) Data loss after nodetool taketoken


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams reopened CASSANDRA-7601:
-

Reproduced In: 1.2.0 beta 1  (was: 2.1.0)

 Data loss after nodetool taketoken
 --

 Key: CASSANDRA-7601
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7601
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tests
 Environment: Mac OSX Mavericks. Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Brandon Williams
Priority: Minor
  Labels: qa-resolved
 Fix For: 2.0.10, 2.1.0

 Attachments: 7601-1.2.txt, 7601-2.0.txt, 7601-2.1.txt, 
 consistent_bootstrap_test.py, taketoken.tar.gz


 The dtest 
 consistent_bootstrap_test.py:TestBootstrapConsistency.consistent_reads_after_relocate_test
  is failing on HEAD of the git branches 2.1 and 2.1.0.
 The test performs the following actions:
 - Create a cluster of 3 nodes
 - Create a keyspace with RF 2
 - Take node 3 down
 - Write 980 rows to node 2 with CL ONE
 - Flush node 2
 - Bring node 3 back up
 - Run nodetool taketoken on node 3 to transfer 80% of node 1's tokens to node 
 3
 - Check for data loss
 When the check for data loss is performed, only ~725 rows can be read via CL 
 ALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7601) Data loss after nodetool taketoken


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-7601:


Attachment: (was: 7601-1.2.txt)

 Data loss after nodetool taketoken
 --

 Key: CASSANDRA-7601
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7601
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tests
 Environment: Mac OSX Mavericks. Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Brandon Williams
Priority: Minor
  Labels: qa-resolved
 Fix For: 2.0.10, 2.1.0

 Attachments: 7601-1.2.txt, 7601-2.0.txt, 7601-2.1.txt, 
 consistent_bootstrap_test.py, taketoken.tar.gz


 The dtest 
 consistent_bootstrap_test.py:TestBootstrapConsistency.consistent_reads_after_relocate_test
  is failing on HEAD of the git branches 2.1 and 2.1.0.
 The test performs the following actions:
 - Create a cluster of 3 nodes
 - Create a keyspace with RF 2
 - Take node 3 down
 - Write 980 rows to node 2 with CL ONE
 - Flush node 2
 - Bring node 3 back up
 - Run nodetool taketoken on node 3 to transfer 80% of node 1's tokens to node 
 3
 - Check for data loss
 When the check for data loss is performed, only ~725 rows can be read via CL 
 ALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7593) Errors when upgrading through several versions to 2.1


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080971#comment-14080971
 ] 

Aleksey Yeschenko commented on CASSANDRA-7593:
--

bq. We don't allow deletions of that form right now, but I agree that it would 
be nice to future-proof a bit here if we can do so safely.

Except I think we do, via Thrift (because stupid CASSANDRA-5435).

 Errors when upgrading through several versions to 2.1
 -

 Key: CASSANDRA-7593
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7593
 Project: Cassandra
  Issue Type: Bug
 Environment: java 1.7
Reporter: Russ Hatch
Assignee: Tyler Hobbs
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-keep-clusteringSize-in-CompoundComposite.patch, 
 7593.txt


 I'm seeing two different errors cropping up in the dtest which upgrades a 
 cluster through several versions.
 This is the more common error:
 {noformat}
 ERROR [GossipStage:10] 2014-07-22 13:14:30,028 CassandraDaemon.java:168 - 
 Exception in thread Thread[GossipStage:10,5,main]
 java.lang.AssertionError: null
 at 
 org.apache.cassandra.db.filter.SliceQueryFilter.shouldInclude(SliceQueryFilter.java:347)
  ~[main/:na]
 at 
 org.apache.cassandra.db.filter.QueryFilter.shouldInclude(QueryFilter.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
  ~[main/:na]
 at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:345) 
 ~[main/:na]
 at 
 org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:293)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:302)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:263)
  ~[main/:na]
 at 
 org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:514)
  ~[main/:na]
 at 
 org.apache.cassandra.net.OutboundTcpConnectionPool.init(OutboundTcpConnectionPool.java:51)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:522)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:536)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:689)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:663)
  ~[main/:na]
 at 
 org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40) 
 ~[main/:na]
 at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
 ~[main/:na]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  ~[na:1.7.0_60]
 at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
 {noformat}
 The same test sometimes fails with this exception instead:
 {noformat}
 ERROR [CompactionExecutor:4] 2014-07-22 16:18:21,008 CassandraDaemon.java:168 
 - Exception in thread Thread[CompactionExecutor:4,1,RMI Runtime]
 java.util.concurrent.RejectedExecutionException: Task 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@7059d3e9 
 rejected from 
 org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor@108f1504[Terminated,
  pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 95]
 at 
 java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) 
 ~[na:1.7.0_60]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530)
  ~[na:1.7.0_60]
 at

[jira] [Updated] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-7567:
--

Fix Version/s: 2.1.0

 when the commit_log disk for a single node is overwhelmed the entire cluster 
 slows down
 ---

 Key: CASSANDRA-7567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, 
 commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy
Reporter: David O'Dell
Assignee: Brandon Williams
 Fix For: 2.1.0

 Attachments: 7567.logs.bz2, write_request_latency.png


 We've run into a situation where a single node out of 14 is experiencing high 
 disk io. This can happen when a node is being decommissioned or after it 
 joins the ring and runs into the bug cassandra-6621.
 When this occurs the write latency for the entire cluster spikes.
 From 0.3ms to 170ms.
 To simulate this simply run dd on the commit_log disk (dd if=/dev/zero 
 of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster 
 have slowed down.
 BTW overwhelming the data disk does not have this same effect.
 Also I've tried this where the overwhelmed node isn't being connected 
 directly from the client and it still has the same effect.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6599) CQL updates should support column = column - { key1, key2, ... } syntax for removing map elements


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081004#comment-14081004
 ] 

Robert Stupp commented on CASSANDRA-6599:
-

bq. not sure I like accepting set literals for map operations.

but a {{map_col - \{'keyFoo', 'keyBar'\}}} is more intutivie IMO - and closer 
to the [syntax to remove set 
elements|http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/update_r.html?scroll=reference_ds_g4h_qzq_xj__using-a-collection-set]


 CQL updates should support column = column - { key1, key2, ... } syntax for 
 removing map elements
 ---

 Key: CASSANDRA-6599
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6599
 Project: Cassandra
  Issue Type: Wish
Reporter: Gavin
Assignee: Benjamin Lerer
Priority: Minor
  Labels: cql
 Fix For: 2.1.1

 Attachments: CASSANDRA-6599.txt


 A variable number number of elements can be removed from lists and sets using 
 an update statement of the form update  set column=column - {} where 
   This syntax should also be supported for map columns.  This would be 
 especially useful for prepared statements (I know that you can use set 
 column[...] = null to remove items in an update statement, but that only 
 works for one element at a time).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6599) CQL updates should support column = column - { key1, key2, ... } syntax for removing map elements


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081013#comment-14081013
 ] 

Aleksey Yeschenko commented on CASSANDRA-6599:
--

More intuitive, but also inconsistent. Looks like trying to subtract a set from 
a map, which looks ugly to me.

Of course I admit that this is subjective. So I'm not closing the issue as 
Won't Fix or Not A Problem, but leave it open instead, until more input.

 CQL updates should support column = column - { key1, key2, ... } syntax for 
 removing map elements
 ---

 Key: CASSANDRA-6599
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6599
 Project: Cassandra
  Issue Type: Wish
Reporter: Gavin
Assignee: Benjamin Lerer
Priority: Minor
  Labels: cql
 Fix For: 2.1.1

 Attachments: CASSANDRA-6599.txt


 A variable number number of elements can be removed from lists and sets using 
 an update statement of the form update  set column=column - {} where 
   This syntax should also be supported for map columns.  This would be 
 especially useful for prepared statements (I know that you can use set 
 column[...] = null to remove items in an update statement, but that only 
 works for one element at a time).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6599) CQL updates should support column = column - { key1, key2, ... } syntax for removing map elements


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081015#comment-14081015
 ] 

Aleksey Yeschenko commented on CASSANDRA-6599:
--

FWIW for the non-prepared case it's also possible to do

{code}
delete map['key1'], map['key2'], map['keyN'] from table where ...;
{code}

to get the same result.

 CQL updates should support column = column - { key1, key2, ... } syntax for 
 removing map elements
 ---

 Key: CASSANDRA-6599
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6599
 Project: Cassandra
  Issue Type: Wish
Reporter: Gavin
Assignee: Benjamin Lerer
Priority: Minor
  Labels: cql
 Fix For: 2.1.1

 Attachments: CASSANDRA-6599.txt


 A variable number number of elements can be removed from lists and sets using 
 an update statement of the form update  set column=column - {} where 
   This syntax should also be supported for map columns.  This would be 
 especially useful for prepared statements (I know that you can use set 
 column[...] = null to remove items in an update statement, but that only 
 works for one element at a time).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7657) tracing doesn't finalize under load when it should

Brandon Williams created CASSANDRA-7657:
---

 Summary: tracing doesn't finalize under load when it should
 Key: CASSANDRA-7657
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7657
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams


If I run stress against a cluster and trace queries in cqlsh, queries that 
complete well within time don't finalize:

{noformat}
session_id   | event_id | 
activity  | source  
  | source_elapsed | thread
--+--+---+---++-
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1130e3a1-18c8-11e4-95bf-4b4842ed69b9 | 
Parsing insert into Standard1 (key, C0) VALUES ( 0xff, 0xff); |  
10.208.8.123 |105 |SharedPool-Worker-12
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1130e3a2-18c8-11e4-95bf-4b4842ed69b9 |  
 Preparing statement |  
10.208.8.123 |450 |SharedPool-Worker-12
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1130e3a3-18c8-11e4-95bf-4b4842ed69b9 |  
   Determining replicas for mutation |  
10.208.8.123 |533 |SharedPool-Worker-12
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 11310ab0-18c8-11e4-95bf-4b4842ed69b9 |  
 Sending message to /10.208.8.63 |  
10.208.8.123 |   1511 |  WRITE-/10.208.8.63
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 113131c0-18c8-11e4-95bf-4b4842ed69b9 |  
   Sending message to /10.208.35.225 |  
10.208.8.123 |   2010 |WRITE-/10.208.35.225
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 113158d0-18c8-11e4-95bf-4b4842ed69b9 |  
  Message received from /10.208.8.63 |  
10.208.8.123 |   3544 |Thread-6
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 11317fe0-18c8-11e4-95bf-4b4842ed69b9 |  
   Processing response from /10.208.8.63 |  
10.208.8.123 |   3718 |SharedPool-Worker-16
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131a6f0-18c8-11e4-95bf-4b4842ed69b9 |  
Message received from /10.208.35.225 |  
10.208.8.123 |   4762 |Thread-3
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131a6f0-18c8-11e4-b290-3b546d897db7 |  
 Message received from /10.208.8.123 |   
10.208.8.63 | 46 |  Thread-346
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131a6f1-18c8-11e4-95bf-4b4842ed69b9 |  
 Processing response from /10.208.35.225 |  
10.208.8.123 |   4938 |SharedPool-Worker-34
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131a6f1-18c8-11e4-b290-3b546d897db7 |  
  Appending to commitlog |   
10.208.8.63 |198 | SharedPool-Worker-7
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131a6f2-18c8-11e4-b290-3b546d897db7 |  
Adding to Standard1 memtable |   
10.208.8.63 |235 | SharedPool-Worker-7
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce00-18c8-11e4-9b6e-517bcdb23258 |  
 Message received from /10.208.8.123 | 
10.208.35.225 | 83 |Thread-4
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce00-18c8-11e4-b290-3b546d897db7 |  
 Enqueuing response to /10.208.8.123 |   
10.208.8.63 |283 | SharedPool-Worker-7
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce01-18c8-11e4-9b6e-517bcdb23258 |  
  Appending to commitlog | 
10.208.35.225 |367 | SharedPool-Worker-4
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce01-18c8-11e4-b290-3b546d897db7 |  
Sending message to bw-1/10.208.8.123 |   
10.208.8.63 |447 | WRITE-bw-1/10.208.8.123
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce02-18c8-11e4-9b6e-517bcdb23258 |  
Adding to Standard1 memtable | 
10.208.35.225 |434 | SharedPool-Worker-4
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce03-18c8-11e4-9b6e-517bcdb23258 |  
 Enqueuing response to /10.208.8.123 | 
10.208.35.225 |494 | SharedPool-Worker-4
 1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131f510-18c8-11e4-9b6e-517bcdb23258 |  
Sending message to bw-1/10.208.8.123 | 
10.208.35.225 |840 | WRITE-bw-1/10.208.8.123
{noformat}

Leaving the duration null:

{noformat}
 session_id   | coordinator  | duration | parameters

[jira] [Updated] (CASSANDRA-7644) tracing does not log commitlog/memtable ops when the coordinator is a replica


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-7644:
--

Attachment: 7644.txt

Two fixes for ATAES:

# newTaskFor(Callable) always created a FT with null TraceState
# TSFT will restore old state instead of assuming it was null

 tracing does not log commitlog/memtable ops when the coordinator is a replica
 -

 Key: CASSANDRA-7644
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7644
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Brandon Williams
 Fix For: 2.1.0

 Attachments: 7644.txt


 For instance:
 {noformat}
  session_id   | event_id 
 | activity  | source  
   | source_elapsed | thread
 --+--+---+---++-
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c4bc1-176f-11e4-8893-4b4842ed69b9 
 | Parsing insert into Standard1 (key, C0) VALUES ( 0xff, 0xff); |  
 10.208.8.123 | 86 | SharedPool-Worker-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c72d0-176f-11e4-8893-4b4842ed69b9 
 |   Preparing statement |  
 10.208.8.123 |434 | SharedPool-Worker-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c72d1-176f-11e4-8893-4b4842ed69b9 
 | Determining replicas for mutation |  
 10.208.8.123 |534 | SharedPool-Worker-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c72d2-176f-11e4-8893-4b4842ed69b9 
 |   Sending message to /10.208.8.63 |  
 10.208.8.123 |   1157 |  WRITE-/10.208.8.63
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c99e0-176f-11e4-8893-4b4842ed69b9 
 | Sending message to /10.208.35.225 |  
 10.208.8.123 |   1975 |WRITE-/10.208.35.225
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d0f10-176f-11e4-8893-4b4842ed69b9 
 |Message received from /10.208.8.63 |  
 10.208.8.123 |   4732 |Thread-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d0f11-176f-11e4-8893-4b4842ed69b9 
 |  Message received from /10.208.35.225 |  
 10.208.8.123 |   5086 |Thread-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3620-176f-11e4-8893-4b4842ed69b9 
 | Processing response from /10.208.8.63 |  
 10.208.8.123 |   5288 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3620-176f-11e4-93e6-517bcdb23258 
 |   Message received from /10.208.8.123 | 
 10.208.35.225 | 76 |Thread-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3620-176f-11e4-9b20-3b546d897db7 
 |   Message received from /10.208.8.123 |   
 10.208.8.63 |317 |Thread-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3621-176f-11e4-8893-4b4842ed69b9 
 |   Processing response from /10.208.35.225 |  
 10.208.8.123 |   5332 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3621-176f-11e4-93e6-517bcdb23258 
 |Appending to commitlog | 
 10.208.35.225 |322 | SharedPool-Worker-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3622-176f-11e4-93e6-517bcdb23258 
 |  Adding to Standard1 memtable | 
 10.208.35.225 |386 | SharedPool-Worker-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3623-176f-11e4-93e6-517bcdb23258 
 |   Enqueuing response to /10.208.8.123 | 
 10.208.35.225 |451 | SharedPool-Worker-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d30-176f-11e4-93e6-517bcdb23258 
 |  Sending message to bw-1/10.208.8.123 | 
 10.208.35.225 |   1538 | WRITE-bw-1/10.208.8.123
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d30-176f-11e4-9b20-3b546d897db7 
 |Appending to commitlog |   
 10.208.8.63 |   1191 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d31-176f-11e4-9b20-3b546d897db7 
 |  Adding to Standard1 memtable |   
 10.208.8.63 |   1226 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d32-176f-11e4-9b20-3b546d897db7 
 |   Enqueuing response to /10.208.8.123 |   
 10.208.8.63 |

[jira] [Resolved] (CASSANDRA-7629) tracing no longer logs when the request completed


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis resolved CASSANDRA-7629.
---

   Resolution: Not a Problem
Fix Version/s: (was: 2.1.1)
 Assignee: (was: Tyler Hobbs)

cqlsh is faking it using info from the sessions table (complete = started_at + 
duration)

 tracing no longer logs when the request completed
 -

 Key: CASSANDRA-7629
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7629
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams
Priority: Minor

 In 2.0 and before, there is a Request complete entry in tracing, which no 
 longer appears in 2.1.  This makes it difficult to reason about 
 latency/performance problems in a trace.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7644) tracing does not log commitlog/memtable ops when the coordinator is a replica


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-7644:
--

  Priority: Minor  (was: Major)
Issue Type: Bug  (was: Improvement)

 tracing does not log commitlog/memtable ops when the coordinator is a replica
 -

 Key: CASSANDRA-7644
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7644
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 2.1.0

 Attachments: 7644.txt


 For instance:
 {noformat}
  session_id   | event_id 
 | activity  | source  
   | source_elapsed | thread
 --+--+---+---++-
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c4bc1-176f-11e4-8893-4b4842ed69b9 
 | Parsing insert into Standard1 (key, C0) VALUES ( 0xff, 0xff); |  
 10.208.8.123 | 86 | SharedPool-Worker-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c72d0-176f-11e4-8893-4b4842ed69b9 
 |   Preparing statement |  
 10.208.8.123 |434 | SharedPool-Worker-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c72d1-176f-11e4-8893-4b4842ed69b9 
 | Determining replicas for mutation |  
 10.208.8.123 |534 | SharedPool-Worker-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c72d2-176f-11e4-8893-4b4842ed69b9 
 |   Sending message to /10.208.8.63 |  
 10.208.8.123 |   1157 |  WRITE-/10.208.8.63
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c99e0-176f-11e4-8893-4b4842ed69b9 
 | Sending message to /10.208.35.225 |  
 10.208.8.123 |   1975 |WRITE-/10.208.35.225
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d0f10-176f-11e4-8893-4b4842ed69b9 
 |Message received from /10.208.8.63 |  
 10.208.8.123 |   4732 |Thread-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d0f11-176f-11e4-8893-4b4842ed69b9 
 |  Message received from /10.208.35.225 |  
 10.208.8.123 |   5086 |Thread-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3620-176f-11e4-8893-4b4842ed69b9 
 | Processing response from /10.208.8.63 |  
 10.208.8.123 |   5288 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3620-176f-11e4-93e6-517bcdb23258 
 |   Message received from /10.208.8.123 | 
 10.208.35.225 | 76 |Thread-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3620-176f-11e4-9b20-3b546d897db7 
 |   Message received from /10.208.8.123 |   
 10.208.8.63 |317 |Thread-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3621-176f-11e4-8893-4b4842ed69b9 
 |   Processing response from /10.208.35.225 |  
 10.208.8.123 |   5332 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3621-176f-11e4-93e6-517bcdb23258 
 |Appending to commitlog | 
 10.208.35.225 |322 | SharedPool-Worker-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3622-176f-11e4-93e6-517bcdb23258 
 |  Adding to Standard1 memtable | 
 10.208.35.225 |386 | SharedPool-Worker-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3623-176f-11e4-93e6-517bcdb23258 
 |   Enqueuing response to /10.208.8.123 | 
 10.208.35.225 |451 | SharedPool-Worker-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d30-176f-11e4-93e6-517bcdb23258 
 |  Sending message to bw-1/10.208.8.123 | 
 10.208.35.225 |   1538 | WRITE-bw-1/10.208.8.123
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d30-176f-11e4-9b20-3b546d897db7 
 |Appending to commitlog |   
 10.208.8.63 |   1191 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d31-176f-11e4-9b20-3b546d897db7 
 |  Adding to Standard1 memtable |   
 10.208.8.63 |   1226 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d32-176f-11e4-9b20-3b546d897db7 
 |   Enqueuing response to /10.208.8.123 |   
 10.208.8.63 |   1277 | SharedPool-Worker-7

[jira] [Updated] (CASSANDRA-7601) Data loss after nodetool taketoken

2014-07-31 Thread Ryan McGuire (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McGuire updated CASSANDRA-7601:


Labels:   (was: qa-resolved)

 Data loss after nodetool taketoken
 --

 Key: CASSANDRA-7601
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7601
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tests
 Environment: Mac OSX Mavericks. Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Brandon Williams
Priority: Minor
 Fix For: 2.0.10, 2.1.0

 Attachments: 7601-1.2.txt, 7601-2.0.txt, 7601-2.1.txt, 
 consistent_bootstrap_test.py, taketoken.tar.gz


 The dtest 
 consistent_bootstrap_test.py:TestBootstrapConsistency.consistent_reads_after_relocate_test
  is failing on HEAD of the git branches 2.1 and 2.1.0.
 The test performs the following actions:
 - Create a cluster of 3 nodes
 - Create a keyspace with RF 2
 - Take node 3 down
 - Write 980 rows to node 2 with CL ONE
 - Flush node 2
 - Bring node 3 back up
 - Run nodetool taketoken on node 3 to transfer 80% of node 1's tokens to node 
 3
 - Check for data loss
 When the check for data loss is performed, only ~725 rows can be read via CL 
 ALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CASSANDRA-7657) tracing doesn't finalize under load when it should


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams resolved CASSANDRA-7657.
-

Resolution: Fixed

7644 solves this as well.

 tracing doesn't finalize under load when it should
 --

 Key: CASSANDRA-7657
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7657
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams

 If I run stress against a cluster and trace queries in cqlsh, queries that 
 complete well within time don't finalize:
 {noformat}
 session_id   | event_id | 
 activity  | source
 | source_elapsed | thread
 --+--+---+---++-
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1130e3a1-18c8-11e4-95bf-4b4842ed69b9 
 | Parsing insert into Standard1 (key, C0) VALUES ( 0xff, 0xff); |  
 10.208.8.123 |105 |SharedPool-Worker-12
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1130e3a2-18c8-11e4-95bf-4b4842ed69b9 
 |   Preparing statement |  
 10.208.8.123 |450 |SharedPool-Worker-12
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1130e3a3-18c8-11e4-95bf-4b4842ed69b9 
 | Determining replicas for mutation |  
 10.208.8.123 |533 |SharedPool-Worker-12
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 11310ab0-18c8-11e4-95bf-4b4842ed69b9 
 |   Sending message to /10.208.8.63 |  
 10.208.8.123 |   1511 |  WRITE-/10.208.8.63
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 113131c0-18c8-11e4-95bf-4b4842ed69b9 
 | Sending message to /10.208.35.225 |  
 10.208.8.123 |   2010 |WRITE-/10.208.35.225
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 113158d0-18c8-11e4-95bf-4b4842ed69b9 
 |Message received from /10.208.8.63 |  
 10.208.8.123 |   3544 |Thread-6
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 11317fe0-18c8-11e4-95bf-4b4842ed69b9 
 | Processing response from /10.208.8.63 |  
 10.208.8.123 |   3718 |SharedPool-Worker-16
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131a6f0-18c8-11e4-95bf-4b4842ed69b9 
 |  Message received from /10.208.35.225 |  
 10.208.8.123 |   4762 |Thread-3
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131a6f0-18c8-11e4-b290-3b546d897db7 
 |   Message received from /10.208.8.123 |   
 10.208.8.63 | 46 |  Thread-346
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131a6f1-18c8-11e4-95bf-4b4842ed69b9 
 |   Processing response from /10.208.35.225 |  
 10.208.8.123 |   4938 |SharedPool-Worker-34
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131a6f1-18c8-11e4-b290-3b546d897db7 
 |Appending to commitlog |   
 10.208.8.63 |198 | SharedPool-Worker-7
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131a6f2-18c8-11e4-b290-3b546d897db7 
 |  Adding to Standard1 memtable |   
 10.208.8.63 |235 | SharedPool-Worker-7
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce00-18c8-11e4-9b6e-517bcdb23258 
 |   Message received from /10.208.8.123 | 
 10.208.35.225 | 83 |Thread-4
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce00-18c8-11e4-b290-3b546d897db7 
 |   Enqueuing response to /10.208.8.123 |   
 10.208.8.63 |283 | SharedPool-Worker-7
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce01-18c8-11e4-9b6e-517bcdb23258 
 |Appending to commitlog | 
 10.208.35.225 |367 | SharedPool-Worker-4
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce01-18c8-11e4-b290-3b546d897db7 
 |  Sending message to bw-1/10.208.8.123 |   
 10.208.8.63 |447 | WRITE-bw-1/10.208.8.123
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce02-18c8-11e4-9b6e-517bcdb23258 
 |  Adding to Standard1 memtable | 
 10.208.35.225 |434 | SharedPool-Worker-4
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131ce03-18c8-11e4-9b6e-517bcdb23258 
 |   Enqueuing response to /10.208.8.123 | 
 10.208.35.225 |494 | SharedPool-Worker-4
  1130e3a0-18c8-11e4-95bf-4b4842ed69b9 | 1131f510-18c8-11e4-9b6e-517bcdb23258 
 |

[jira] [Comment Edited] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down

[
https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081040#comment-14081040
]

Brandon Williams edited comment on CASSANDRA-7567 at 7/31/14 4:04 PM:
--

I applied CASSANDRA-7644 and finally got meaningful traces, but none were
fruitful - everything always completed quickly and exactly as it should. So I
went for the sure-fire method of reproducing, and suspended the jvm on the 'dd'
node so it couldn't respond at all. Still nothing suspicious in the trace,
however now I _did_ see stress report 12s latencies. Suspecting that stress
wasn't actually doing what I told it to (only connect to node1 and node2, not
node3 which I'm trying to beat up with dd) I discovered it was actually
connecting to all three nodes, and that's why suspending the 'unused' node
caused the latencies.

I don't think anything is wrong in Cassandra itself here any longer, but
something is wrong with stress, probably doing ring discovery and connecting to
everything when it shouldn't.

was (Author: brandon.williams):
I applied CASSANDRA-7644 and finally got meaningful traces, but none were
fruitful - everything always completed quickly and exactly as it should. So I
went for the sure-fire method of reproducing, and suspended the jvm on the 'dd'
node so it could respond at all. Still nothing suspicious in the trace,
however now I _did_ see stress report 12s latencies. Suspecting that stress
wasn't actually doing what I told it to (only connect to node1 and node2, not
node3 which I'm trying to beat up with dd) I discovered it was actually
connecting to all three nodes, and that's why suspending the 'unused' node
caused the latencies.

I don't think anything is wrong in Cassandra itself here any longer, but
something is wrong with stress, probably doing ring discovery and connecting to
everything when it shouldn't.

when the commit_log disk for a single node is overwhelmed the entire cluster
slows down
---

Key: CASSANDRA-7567
URL: https://issues.apache.org/jira/browse/CASSANDRA-7567
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM,
commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy
Reporter: David O'Dell
Assignee: Brandon Williams
Fix For: 2.1.0

Attachments: 7567.logs.bz2, write_request_latency.png

We've run into a situation where a single node out of 14 is experiencing high
disk io. This can happen when a node is being decommissioned or after it
joins the ring and runs into the bug cassandra-6621.
When this occurs the write latency for the entire cluster spikes.
From 0.3ms to 170ms.
To simulate this simply run dd on the commit_log disk (dd if=/dev/zero
of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster
have slowed down.
BTW overwhelming the data disk does not have this same effect.
Also I've tried this where the overwhelmed node isn't being connected
directly from the client and it still has the same effect.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down

[
https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081040#comment-14081040
]

Brandon Williams commented on CASSANDRA-7567:
-

I applied CASSANDRA-7644 and finally got meaningful traces, but none were
fruitful - everything always completed quickly and exactly as it should. So I
went for the sure-fire method of reproducing, and suspended the jvm on the 'dd'
node so it could respond at all. Still nothing suspicious in the trace,
however now I _did_ see stress report 12s latencies. Suspecting that stress
wasn't actually doing what I told it to (only connect to node1 and node2, not
node3 which I'm trying to beat up with dd) I discovered it was actually
connecting to all three nodes, and that's why suspending the 'unused' node
caused the latencies.

I don't think anything is wrong in Cassandra itself here any longer, but
something is wrong with stress, probably doing ring discovery and connecting to
everything when it shouldn't.

when the commit_log disk for a single node is overwhelmed the entire cluster
slows down
---

Attachments: 7567.logs.bz2, write_request_latency.png

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down

[
https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081045#comment-14081045
]

Benedict commented on CASSANDRA-7567:
-

Which mode of connectivity? smart thrift and cql native3 both use token aware
routing from the Java driver (smart thrift does its own fairly dumb round-robin
for a given token range), so will go directly to a random node in the cluster.
Java driver I don't think we have any easy API control over what nodes we
connect to, and I'm not sure there's a lot of point making smart thrift too
smart, since it's only there to compare fairly against cql native3's
token-aware routing. Regular thrift mode won't do this.

when the commit_log disk for a single node is overwhelmed the entire cluster
slows down
---

Attachments: 7567.logs.bz2, write_request_latency.png

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7658) stress connects to all nodes when it shouldn't

Brandon Williams created CASSANDRA-7658:
---

 Summary: stress connects to all nodes when it shouldn't
 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
 Fix For: 2.1.1


If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
ring discovery and connect to them all anyway (checked via netstat.)  This led 
to the confusion on CASSANDRA-7601.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7658) stress connects to all nodes when it shouldn't


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-7658:
--

Description: If you tell stress -node 1,2 in cluster with more nodes, 
stress appears to do ring discovery and connect to them all anyway (checked via 
netstat.)  This led to the confusion on CASSANDRA-7657  (was: If you tell 
stress -node 1,2 in cluster with more nodes, stress appears to do ring 
discovery and connect to them all anyway (checked via netstat.)  This led to 
the confusion on CASSANDRA-7601.)

 stress connects to all nodes when it shouldn't
 --

 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
 Fix For: 2.1.1


 If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
 ring discovery and connect to them all anyway (checked via netstat.)  This 
 led to the confusion on CASSANDRA-7657



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081049#comment-14081049
 ] 

Brandon Williams commented on CASSANDRA-7567:
-

Whichever mode is the default.  My command line is pretty simple:

{noformat}
tools/bin/cassandra-stress write n=1000 -node bw-1,bw-2 -schema 
'replication(factor=3)'
{noformat}

 when the commit_log disk for a single node is overwhelmed the entire cluster 
 slows down
 ---

 Key: CASSANDRA-7567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, 
 commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy
Reporter: David O'Dell
Assignee: Brandon Williams
 Fix For: 2.1.0

 Attachments: 7567.logs.bz2, write_request_latency.png


 We've run into a situation where a single node out of 14 is experiencing high 
 disk io. This can happen when a node is being decommissioned or after it 
 joins the ring and runs into the bug cassandra-6621.
 When this occurs the write latency for the entire cluster spikes.
 From 0.3ms to 170ms.
 To simulate this simply run dd on the commit_log disk (dd if=/dev/zero 
 of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster 
 have slowed down.
 BTW overwhelming the data disk does not have this same effect.
 Also I've tried this where the overwhelmed node isn't being connected 
 directly from the client and it still has the same effect.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7658) stress connects to all nodes when it shouldn't


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-7658:
--

Description: If you tell stress -node 1,2 in cluster with more nodes, 
stress appears to do ring discovery and connect to them all anyway (checked via 
netstat.)  This led to the confusion on CASSANDRA-7567  (was: If you tell 
stress -node 1,2 in cluster with more nodes, stress appears to do ring 
discovery and connect to them all anyway (checked via netstat.)  This led to 
the confusion on CASSANDRA-7657)

 stress connects to all nodes when it shouldn't
 --

 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
 Fix For: 2.1.1


 If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
 ring discovery and connect to them all anyway (checked via netstat.)  This 
 led to the confusion on CASSANDRA-7567



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081060#comment-14081060
 ] 

Benedict commented on CASSANDRA-7567:
-

So Java driver then (cql3 native prepared is default) There isn't anything we 
can really do about this without Java Driver support

 when the commit_log disk for a single node is overwhelmed the entire cluster 
 slows down
 ---

 Key: CASSANDRA-7567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, 
 commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy
Reporter: David O'Dell
Assignee: Brandon Williams
 Attachments: 7567.logs.bz2, write_request_latency.png


 We've run into a situation where a single node out of 14 is experiencing high 
 disk io. This can happen when a node is being decommissioned or after it 
 joins the ring and runs into the bug cassandra-6621.
 When this occurs the write latency for the entire cluster spikes.
 From 0.3ms to 170ms.
 To simulate this simply run dd on the commit_log disk (dd if=/dev/zero 
 of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster 
 have slowed down.
 BTW overwhelming the data disk does not have this same effect.
 Also I've tried this where the overwhelmed node isn't being connected 
 directly from the client and it still has the same effect.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081059#comment-14081059
 ] 

Brandon Williams commented on CASSANDRA-7567:
-

Closing in favor of CASSANDRA-7658

 when the commit_log disk for a single node is overwhelmed the entire cluster 
 slows down
 ---

 Key: CASSANDRA-7567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, 
 commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy
Reporter: David O'Dell
Assignee: Brandon Williams
 Attachments: 7567.logs.bz2, write_request_latency.png


 We've run into a situation where a single node out of 14 is experiencing high 
 disk io. This can happen when a node is being decommissioned or after it 
 joins the ring and runs into the bug cassandra-6621.
 When this occurs the write latency for the entire cluster spikes.
 From 0.3ms to 170ms.
 To simulate this simply run dd on the commit_log disk (dd if=/dev/zero 
 of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster 
 have slowed down.
 BTW overwhelming the data disk does not have this same effect.
 Also I've tried this where the overwhelmed node isn't being connected 
 directly from the client and it still has the same effect.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams resolved CASSANDRA-7567.
-

   Resolution: Not a Problem
Fix Version/s: (was: 2.1.0)

 when the commit_log disk for a single node is overwhelmed the entire cluster 
 slows down
 ---

 Key: CASSANDRA-7567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, 
 commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy
Reporter: David O'Dell
Assignee: Brandon Williams
 Attachments: 7567.logs.bz2, write_request_latency.png


 We've run into a situation where a single node out of 14 is experiencing high 
 disk io. This can happen when a node is being decommissioned or after it 
 joins the ring and runs into the bug cassandra-6621.
 When this occurs the write latency for the entire cluster spikes.
 From 0.3ms to 170ms.
 To simulate this simply run dd on the commit_log disk (dd if=/dev/zero 
 of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster 
 have slowed down.
 BTW overwhelming the data disk does not have this same effect.
 Also I've tried this where the overwhelmed node isn't being connected 
 directly from the client and it still has the same effect.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7658) stress connects to all nodes when it shouldn't


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedict updated CASSANDRA-7658:


Issue Type: Improvement  (was: Bug)

 stress connects to all nodes when it shouldn't
 --

 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
 Fix For: 2.1.1


 If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
 ring discovery and connect to them all anyway (checked via netstat.)  This 
 led to the confusion on CASSANDRA-7567



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7658) stress connects to all nodes when it shouldn't


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081065#comment-14081065
 ] 

Russell Alexander Spitzer commented on CASSANDRA-7658:
--

I'm mixed on this. I really like the discovery that you get with a default 
connection but we should have the ability to use the whitelist policy with 
specific nodes as well. 

 stress connects to all nodes when it shouldn't
 --

 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
Priority: Minor
 Fix For: 2.1.1


 If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
 ring discovery and connect to them all anyway (checked via netstat.)  This 
 led to the confusion on CASSANDRA-7567



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7658) stress connects to all nodes when it shouldn't


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedict updated CASSANDRA-7658:


Priority: Minor  (was: Major)

 stress connects to all nodes when it shouldn't
 --

 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
Priority: Minor
 Fix For: 2.1.1


 If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
 ring discovery and connect to them all anyway (checked via netstat.)  This 
 led to the confusion on CASSANDRA-7567



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7658) stress connects to all nodes when it shouldn't


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081068#comment-14081068
 ] 

Russell Alexander Spitzer commented on CASSANDRA-7658:
--

Java driver does support this,
http://www.datastax.com/drivers/java/2.0/com/datastax/driver/core/policies/WhiteListPolicy.html
So it can be implemented

 stress connects to all nodes when it shouldn't
 --

 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
Priority: Minor
 Fix For: 2.1.1


 If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
 ring discovery and connect to them all anyway (checked via netstat.)  This 
 led to the confusion on CASSANDRA-7567



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7658) stress connects to all nodes when it shouldn't


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081063#comment-14081063
 ] 

Benedict commented on CASSANDRA-7658:
-

You're inferring a property of the 'node' option it doesn't promise; that's the 
list of nodes it connects to initially to get started. You're looking for a 
whitelist, which is a different thing, and not currently supported. For dumb 
routing it necessarily behaves as both, but this is a feature request not a bug.

Either way, we need Java Driver support that I don't think currently exists via 
the API.

 stress connects to all nodes when it shouldn't
 --

 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
Priority: Minor
 Fix For: 2.1.1


 If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
 ring discovery and connect to them all anyway (checked via netstat.)  This 
 led to the confusion on CASSANDRA-7567



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7658) stress connects to all nodes when it shouldn't


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081067#comment-14081067
 ] 

Brandon Williams commented on CASSANDRA-7658:
-

bq. You're looking for a whitelist, which is a different thing, and not 
currently supported

Well, old-stress supported it and it's useful in a lot of test scenarios.

 stress connects to all nodes when it shouldn't
 --

 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
Priority: Minor
 Fix For: 2.1.1


 If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
 ring discovery and connect to them all anyway (checked via netstat.)  This 
 led to the confusion on CASSANDRA-7567



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7658) stress connects to all nodes when it shouldn't


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081066#comment-14081066
 ] 

Brandon Williams commented on CASSANDRA-7658:
-

bq. So Java driver then (cql3 native prepared is default) There isn't anything 
we can really do about this without Java Driver support

Barring that, I think we should at least warn (though I'd prefer erroring out) 
when the -node flag is passed in that mode, since it obviously doesn't do what 
you're intending.

 stress connects to all nodes when it shouldn't
 --

 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
Priority: Minor
 Fix For: 2.1.1


 If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
 ring discovery and connect to them all anyway (checked via netstat.)  This 
 led to the confusion on CASSANDRA-7567



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7311) Enable incremental backup on a per-keyspace level


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-7311:
-

Fix Version/s: 2.1.1

 Enable incremental backup on a per-keyspace level
 -

 Key: CASSANDRA-7311
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7311
 Project: Cassandra
  Issue Type: Improvement
Reporter: Johnny Miller
Assignee: pankaj mishra
Priority: Minor
  Labels: lhf
 Fix For: 2.1.1

 Attachments: 7311-cqlsh-update.txt, cassandra-rebased-2.1.patch, 
 table_incremental_7311.patch


 Currently incremental backups are globally defined, however this is not 
 always appropriate or required for all keyspaces in a cluster. 
 As this is quite expensive, it would be preferred to either specify the 
 keyspaces that need this (or exclude the ones that don't).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7658) stress connects to all nodes when it shouldn't


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081071#comment-14081071
 ] 

Benedict commented on CASSANDRA-7658:
-

old-stress has no distinction between a whitelist and an initial list.

 stress connects to all nodes when it shouldn't
 --

 Key: CASSANDRA-7658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7658
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Brandon Williams
Assignee: Benedict
Priority: Minor
 Fix For: 2.1.1


 If you tell stress -node 1,2 in cluster with more nodes, stress appears to do 
 ring discovery and connect to them all anyway (checked via netstat.)  This 
 led to the confusion on CASSANDRA-7567



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6599) CQL updates should support column = column - { key1, key2, ... } syntax for removing map elements

2014-07-31 Thread Gavin (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081073#comment-14081073
 ] 

Gavin commented on CASSANDRA-6599:
--

Either syntax would work for me, the {{map = map + \{'key1': null, 'key2': 
null\}...}} option has the advantage that it allows insert/update/delete to be 
combined (i.e. {{map = map + \{ 'key-to-delete': null, 'key-to-add/update': 
'value'\}...}}).  I did test it using Cassandra 2.1.0-rc4 though cqlsh and java 
driver 2.0.3 but it did not work for me, I've pasted the error messages below 
for reference.

from CQLSH:
code=2200 \[Invalid query\] message=null is not supported inside collections

from java driver using a prepared statement:
Exception in thread main java.lang.NullPointerException
at java.nio.CharBuffer.wrap(CharBuffer.java:483)
at com.datastax.driver.core.TypeCodec$StringCodec.serialize(TypeCodec.java:264)
...

from the java driver using a non-prepared statement:
Exception in thread main 
com.datastax.driver.core.exceptions.InvalidQueryException: null is not 
supported inside collections
...

 CQL updates should support column = column - { key1, key2, ... } syntax for 
 removing map elements
 ---

 Key: CASSANDRA-6599
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6599
 Project: Cassandra
  Issue Type: Wish
Reporter: Gavin
Assignee: Benjamin Lerer
Priority: Minor
  Labels: cql
 Fix For: 2.1.1

 Attachments: CASSANDRA-6599.txt


 A variable number number of elements can be removed from lists and sets using 
 an update statement of the form update  set column=column - {} where 
   This syntax should also be supported for map columns.  This would be 
 especially useful for prepared statements (I know that you can use set 
 column[...] = null to remove items in an update statement, but that only 
 works for one element at a time).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6599) CQL updates should support column = column - { key1, key2, ... } syntax for removing map elements


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081085#comment-14081085
 ] 

Aleksey Yeschenko commented on CASSANDRA-6599:
--

I *think* we should be able to lift the null-restriction from map values - 
don't remember why we have it there in the first place. Will look into it.

 CQL updates should support column = column - { key1, key2, ... } syntax for 
 removing map elements
 ---

 Key: CASSANDRA-6599
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6599
 Project: Cassandra
  Issue Type: Wish
Reporter: Gavin
Assignee: Benjamin Lerer
Priority: Minor
  Labels: cql
 Fix For: 2.1.1

 Attachments: CASSANDRA-6599.txt


 A variable number number of elements can be removed from lists and sets using 
 an update statement of the form update  set column=column - {} where 
   This syntax should also be supported for map columns.  This would be 
 especially useful for prepared statements (I know that you can use set 
 column[...] = null to remove items in an update statement, but that only 
 works for one element at a time).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7631) Allow Stress to write directly to SSTables


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081098#comment-14081098
 ] 

Russell Alexander Spitzer commented on CASSANDRA-7631:
--

I have a few idea's I'd like to try out first :) This has given me a good 
chance to see how new stress works.

 Allow Stress to write directly to SSTables
 --

 Key: CASSANDRA-7631
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7631
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Russell Alexander Spitzer
Assignee: Russell Alexander Spitzer

 One common difficulty with benchmarking machines is the amount of time it 
 takes to initially load data. For machines with a large amount of ram this 
 becomes especially onerous because a very large amount of data needs to be 
 placed on the machine before page-cache can be circumvented. 
 To remedy this I suggest we add a top level flag to Cassandra-Stress which 
 would cause the tool to write directly to sstables rather than actually 
 performing CQL inserts. Internally this would use CQLSStable writer to write 
 directly to sstables while skipping any keys which are not owned by the node 
 stress is running on. The same stress command run on each node in the cluster 
 would then write unique sstables only containing data which that node is 
 responsible for. Following this no further network IO would be required to 
 distribute data as it would all already be correctly in place.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CASSANDRA-7631) Allow Stress to write directly to SSTables


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedict reassigned CASSANDRA-7631:
---

Assignee: Benedict  (was: Russell Alexander Spitzer)

 Allow Stress to write directly to SSTables
 --

 Key: CASSANDRA-7631
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7631
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Russell Alexander Spitzer
Assignee: Benedict

 One common difficulty with benchmarking machines is the amount of time it 
 takes to initially load data. For machines with a large amount of ram this 
 becomes especially onerous because a very large amount of data needs to be 
 placed on the machine before page-cache can be circumvented. 
 To remedy this I suggest we add a top level flag to Cassandra-Stress which 
 would cause the tool to write directly to sstables rather than actually 
 performing CQL inserts. Internally this would use CQLSStable writer to write 
 directly to sstables while skipping any keys which are not owned by the node 
 stress is running on. The same stress command run on each node in the cluster 
 would then write unique sstables only containing data which that node is 
 responsible for. Following this no further network IO would be required to 
 distribute data as it would all already be correctly in place.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7631) Allow Stress to write directly to SSTables


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedict updated CASSANDRA-7631:


Assignee: Russell Alexander Spitzer  (was: Benedict)

 Allow Stress to write directly to SSTables
 --

 Key: CASSANDRA-7631
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7631
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Russell Alexander Spitzer
Assignee: Russell Alexander Spitzer

 One common difficulty with benchmarking machines is the amount of time it 
 takes to initially load data. For machines with a large amount of ram this 
 becomes especially onerous because a very large amount of data needs to be 
 placed on the machine before page-cache can be circumvented. 
 To remedy this I suggest we add a top level flag to Cassandra-Stress which 
 would cause the tool to write directly to sstables rather than actually 
 performing CQL inserts. Internally this would use CQLSStable writer to write 
 directly to sstables while skipping any keys which are not owned by the node 
 stress is running on. The same stress command run on each node in the cluster 
 would then write unique sstables only containing data which that node is 
 responsible for. Following this no further network IO would be required to 
 distribute data as it would all already be correctly in place.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7631) Allow Stress to write directly to SSTables


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081116#comment-14081116
 ] 

Benedict commented on CASSANDRA-7631:
-

Ok, in that case some various random thoughts on this:

1) I suspect you're not blocking on ABQ, but on the single thread you have 
consuming from it (and having this separate thread is bad anyway). It's likely 
you're getting some misattribution in your profiler due to rapid thread 
sleeping/waking there.
2) We should for now complain if the whole partition isn't being inserted for 
this mode
3) We should create the CF on each individual thread, and we should append them 
unsorted onto a ConcurrentLinkedQueue, track the total memory used in the 
buffer, and have a separate thread that sorts the partition keys and flushes 
out to disk once we exceed our threshold for doing so (much like memtable 
flushing)
4) We should modify the PartitionGenerator to support sorting the clustering 
components it generates; this way we can reduce the sorting cost fairly 
dramatically, as sorting individual components is much cheaper than sorting all 
components at once
5) Ideally we would visit the partition keys in approximately sorted order, so 
that we can flush a single file, as this will be most efficient for loading. 
This will require a minor portion of the changes I'll be introducing soon for 
more realistic workload generation, and then a custom SeedGenerator that 
(externally) pre-sorts the seeds based on the partitions they generate.


 Allow Stress to write directly to SSTables
 --

 Key: CASSANDRA-7631
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7631
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Russell Alexander Spitzer
Assignee: Russell Alexander Spitzer

 One common difficulty with benchmarking machines is the amount of time it 
 takes to initially load data. For machines with a large amount of ram this 
 becomes especially onerous because a very large amount of data needs to be 
 placed on the machine before page-cache can be circumvented. 
 To remedy this I suggest we add a top level flag to Cassandra-Stress which 
 would cause the tool to write directly to sstables rather than actually 
 performing CQL inserts. Internally this would use CQLSStable writer to write 
 directly to sstables while skipping any keys which are not owned by the node 
 stress is running on. The same stress command run on each node in the cluster 
 would then write unique sstables only containing data which that node is 
 responsible for. Following this no further network IO would be required to 
 distribute data as it would all already be correctly in place.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7593) Errors when upgrading through several versions to 2.1

2014-07-31 Thread Tyler Hobbs (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081121#comment-14081121
 ] 

Tyler Hobbs commented on CASSANDRA-7593:


Let's take a step back.

Moving {{clusteringSize()}} up to Composite creates problems for 
CompoundComposite, as Marcus demonstrated, because the CompoundComposite isn't 
capable of knowing its own clustering size.  We would need to patch all of the 
places where we create CompoundComposites (which Marcus started) in order to 
avoid a lot of subtle bugs in the future.

Instead of moving {{clusteringSize()}} up to the Composite class, can't we 
utilize the {{comparator}} in {{ColumnNameHelper.min/maxComponents()}}?  For 
example, what we have now is:

{code}
public static ListByteBuffer minComponents(ListByteBuffer minSeen, 
Composite candidate, CellNameType comparator)
{
// For a cell name, no reason to look more than the clustering prefix
// (and comparing the collection element would actually crash)
int size = candidate instanceof CellName ? 
((CellName)candidate).clusteringSize() : candidate.size();

if (minSeen.isEmpty())
return getComponents(candidate, size);
{code}

Instead, we can do:
{code}
int size = min(comparator.clusteringPrefixSize(), candidate.size());

if (minSeen.isEmpty())
return getComponents(candidate, size);
{code}

We would definitely need to do CASSANDRA-7651 along with this (especially due 
to CASSANDRA-5435), but it seems like the least risky, most correct fix to me.

 Errors when upgrading through several versions to 2.1
 -

 Key: CASSANDRA-7593
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7593
 Project: Cassandra
  Issue Type: Bug
 Environment: java 1.7
Reporter: Russ Hatch
Assignee: Tyler Hobbs
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-keep-clusteringSize-in-CompoundComposite.patch, 
 7593.txt


 I'm seeing two different errors cropping up in the dtest which upgrades a 
 cluster through several versions.
 This is the more common error:
 {noformat}
 ERROR [GossipStage:10] 2014-07-22 13:14:30,028 CassandraDaemon.java:168 - 
 Exception in thread Thread[GossipStage:10,5,main]
 java.lang.AssertionError: null
 at 
 org.apache.cassandra.db.filter.SliceQueryFilter.shouldInclude(SliceQueryFilter.java:347)
  ~[main/:na]
 at 
 org.apache.cassandra.db.filter.QueryFilter.shouldInclude(QueryFilter.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:249)
  ~[main/:na]
 at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
  ~[main/:na]
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
  ~[main/:na]
 at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:345) 
 ~[main/:na]
 at 
 org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:293)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:302)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:60)
  ~[main/:na]
 at 
 org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:263)
  ~[main/:na]
 at 
 org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:514)
  ~[main/:na]
 at 
 org.apache.cassandra.net.OutboundTcpConnectionPool.init(OutboundTcpConnectionPool.java:51)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:522)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:536)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:689)
  ~[main/:na]
 at 
 org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:663)
  ~[main/:na]
 at 
 org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40) 
 ~[main/:na]
 at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
 ~[main/:na]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_60]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  ~[na:1.7.0_60]
 at

[jira] [Commented] (CASSANDRA-7644) tracing does not log commitlog/memtable ops when the coordinator is a replica


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081129#comment-14081129
 ] 

Benedict commented on CASSANDRA-7644:
-

LGTM

 tracing does not log commitlog/memtable ops when the coordinator is a replica
 -

 Key: CASSANDRA-7644
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7644
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 2.1.0

 Attachments: 7644.txt


 For instance:
 {noformat}
  session_id   | event_id 
 | activity  | source  
   | source_elapsed | thread
 --+--+---+---++-
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c4bc1-176f-11e4-8893-4b4842ed69b9 
 | Parsing insert into Standard1 (key, C0) VALUES ( 0xff, 0xff); |  
 10.208.8.123 | 86 | SharedPool-Worker-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c72d0-176f-11e4-8893-4b4842ed69b9 
 |   Preparing statement |  
 10.208.8.123 |434 | SharedPool-Worker-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c72d1-176f-11e4-8893-4b4842ed69b9 
 | Determining replicas for mutation |  
 10.208.8.123 |534 | SharedPool-Worker-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c72d2-176f-11e4-8893-4b4842ed69b9 
 |   Sending message to /10.208.8.63 |  
 10.208.8.123 |   1157 |  WRITE-/10.208.8.63
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1c99e0-176f-11e4-8893-4b4842ed69b9 
 | Sending message to /10.208.35.225 |  
 10.208.8.123 |   1975 |WRITE-/10.208.35.225
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d0f10-176f-11e4-8893-4b4842ed69b9 
 |Message received from /10.208.8.63 |  
 10.208.8.123 |   4732 |Thread-5
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d0f11-176f-11e4-8893-4b4842ed69b9 
 |  Message received from /10.208.35.225 |  
 10.208.8.123 |   5086 |Thread-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3620-176f-11e4-8893-4b4842ed69b9 
 | Processing response from /10.208.8.63 |  
 10.208.8.123 |   5288 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3620-176f-11e4-93e6-517bcdb23258 
 |   Message received from /10.208.8.123 | 
 10.208.35.225 | 76 |Thread-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3620-176f-11e4-9b20-3b546d897db7 
 |   Message received from /10.208.8.123 |   
 10.208.8.63 |317 |Thread-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3621-176f-11e4-8893-4b4842ed69b9 
 |   Processing response from /10.208.35.225 |  
 10.208.8.123 |   5332 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3621-176f-11e4-93e6-517bcdb23258 
 |Appending to commitlog | 
 10.208.35.225 |322 | SharedPool-Worker-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3622-176f-11e4-93e6-517bcdb23258 
 |  Adding to Standard1 memtable | 
 10.208.35.225 |386 | SharedPool-Worker-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d3623-176f-11e4-93e6-517bcdb23258 
 |   Enqueuing response to /10.208.8.123 | 
 10.208.35.225 |451 | SharedPool-Worker-4
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d30-176f-11e4-93e6-517bcdb23258 
 |  Sending message to bw-1/10.208.8.123 | 
 10.208.35.225 |   1538 | WRITE-bw-1/10.208.8.123
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d30-176f-11e4-9b20-3b546d897db7 
 |Appending to commitlog |   
 10.208.8.63 |   1191 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d31-176f-11e4-9b20-3b546d897db7 
 |  Adding to Standard1 memtable |   
 10.208.8.63 |   1226 | SharedPool-Worker-7
  bb1c4bc0-176f-11e4-8893-4b4842ed69b9 | bb1d5d32-176f-11e4-9b20-3b546d897db7 
 |   Enqueuing response to /10.208.8.123 |   
 10.208.8.63 |   1277 | SharedPool-Worker-7

[jira] [Commented] (CASSANDRA-7631) Allow Stress to write directly to SSTables

[
https://issues.apache.org/jira/browse/CASSANDRA-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081134#comment-14081134
]

Russell Alexander Spitzer commented on CASSANDRA-7631:
--

I eliminated my first bottleneck. I was putting every logical row onto the
ABQ which ends up being bad news when there are 300k a second. Instead I know
put a list of logical rows (one for each work unit) onto the ABQ and I can
keep up with the generation now up to 8 generating threads with still just 1
consumer. 73k pk/s .

I'll check with a greater number of generators to see if I can keep up still.

Allow Stress to write directly to SSTables
--

Key: CASSANDRA-7631
URL: https://issues.apache.org/jira/browse/CASSANDRA-7631
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Russell Alexander Spitzer
Assignee: Russell Alexander Spitzer

One common difficulty with benchmarking machines is the amount of time it
takes to initially load data. For machines with a large amount of ram this
becomes especially onerous because a very large amount of data needs to be
placed on the machine before page-cache can be circumvented.
To remedy this I suggest we add a top level flag to Cassandra-Stress which
would cause the tool to write directly to sstables rather than actually
performing CQL inserts. Internally this would use CQLSStable writer to write
directly to sstables while skipping any keys which are not owned by the node
stress is running on. The same stress command run on each node in the cluster
would then write unique sstables only containing data which that node is
responsible for. Following this no further network IO would be required to
distribute data as it would all already be correctly in place.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7593) Errors when upgrading through several versions to 2.1