[jira] [Commented] (CASSANDRA-7288) Exception during compaction

[Marcus Eriksson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010816#comment-14010816
 ] 

Marcus Eriksson commented on CASSANDRA-7288:


[~anguenot] this will be included in 2.0.9, if you have the possibility to test 
it before that is released, it would be appreciated

> Exception during compaction
> ---
>
> Key: CASSANDRA-7288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7288
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Julien Anguenot
>Assignee: Marcus Eriksson
> Fix For: 2.0.9
>
> Attachments: 
> 0001-make-sure-we-don-t-try-to-compact-already-compacting.patch, 
> compaction_exception.txt
>
>
> Sometimes Cassandra nodes (in a multi datacenter deployment) are throwing 
> errors during compaction. (see attached stack trace)
> Let me know what additional information I could provide.
> Thank you.



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

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

[marcuse]

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/fc7ccb8b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fc7ccb8b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fc7ccb8b

Branch: refs/heads/trunk
Commit: fc7ccb8bddb5cac0106ca602864df4dded22a372
Parents: 707eabd 5b31449
Author: Marcus Eriksson 
Authored: Wed May 28 07:45:41 2014 +0200
Committer: Marcus Eriksson 
Committed: Wed May 28 07:45:41 2014 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/HintedHandOffManager.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


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

[1/3] git commit: Make sure we don't try to compact already compacting sstables in HHOM

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 707eabdc9 -> fc7ccb8bd


Make sure we don't try to compact already compacting sstables in HHOM

Patch by marcuse; reviewed by jbellis for CASSANDRA-7288


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

Branch: refs/heads/trunk
Commit: 54618a1b3eb3783643d450b28e40862f3bed45c3
Parents: 81286b0
Author: Marcus Eriksson 
Authored: Tue May 27 11:12:27 2014 +0200
Committer: Marcus Eriksson 
Committed: Wed May 28 07:43:47 2014 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/HintedHandOffManager.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/54618a1b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6a16cae..2b8ce60 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -4,6 +4,7 @@
  * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
  * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
  * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
+ * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
 
 2.0.8
  * Always reallocate buffers in HSHA (CASSANDRA-6285)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/54618a1b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
--
diff --git a/src/java/org/apache/cassandra/db/HintedHandOffManager.java 
b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
index 13d1bb0..158f6ad 100644
--- a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
+++ b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
@@ -254,7 +254,7 @@ public class HintedHandOffManager implements 
HintedHandOffManagerMBean
 {
 hintStore.forceBlockingFlush();
 ArrayList descriptors = new ArrayList();
-for (SSTable sstable : hintStore.getSSTables())
+for (SSTable sstable : 
hintStore.getDataTracker().getUncompactingSSTables())
 descriptors.add(sstable.descriptor);
 return CompactionManager.instance.submitUserDefined(hintStore, 
descriptors, (int) (System.currentTimeMillis() / 1000));
 }

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

[marcuse]

Merge branch 'cassandra-2.0' into cassandra-2.1

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/5b314490
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5b314490
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5b314490

Branch: refs/heads/trunk
Commit: 5b3144905f08f47e114188647b570450631180a9
Parents: 8cb5058 54618a1
Author: Marcus Eriksson 
Authored: Wed May 28 07:45:24 2014 +0200
Committer: Marcus Eriksson 
Committed: Wed May 28 07:45:24 2014 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/HintedHandOffManager.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5b314490/CHANGES.txt
--
diff --cc CHANGES.txt
index 6240e1e,2b8ce60..a71867a
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,33 -1,12 +1,34 @@@
 -2.0.9
 - * Add missing iso8601 patterns for date strings (6973)
 - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
 - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
 +2.1.0-rc1
 + * Add tab-completion to debian nodetool packaging (CASSANDRA-6421)
 + * Change concurrent_compactors defaults (CASSANDRA-7139)
 + * Add PowerShell Windows launch scripts (CASSANDRA-7001)
 + * Make commitlog archive+restore more robust (CASSANDRA-6974)
 + * Fix marking commitlogsegments clean (CASSANDRA-6959)
 + * Add snapshot "manifest" describing files included (CASSANDRA-6326)
 + * Parallel streaming for sstableloader (CASSANDRA-3668)
 + * Fix bugs in supercolumns handling (CASSANDRA-7138)
 + * Fix ClassClassException on composite dense tables (CASSANDRA-7112)
 + * Cleanup and optimize collation and slice iterators (CASSANDRA-7107)
 + * Upgrade NBHM lib (CASSANDRA-7128)
 + * Optimize netty server (CASSANDRA-6861)
 + * Fix repair hang when given CF does not exist (CASSANDRA-7189)
 + * Allow c* to be shutdown in an embedded mode (CASSANDRA-5635)
 + * Add server side batching to native transport (CASSANDRA-5663)
 + * Make batchlog replay asynchronous (CASSANDRA-6134)
 + * remove unused classes (CASSANDRA-7197)
 + * Limit user types to the keyspace they are defined in (CASSANDRA-6643)
 + * Add validate method to CollectionType (CASSANDRA-7208)
 + * New serialization format for UDT values (CASSANDRA-7209, CASSANDRA-7261)
 + * Fix nodetool netstats (CASSANDRA-7270)
 + * Fix potential ClassCastException in HintedHandoffManager (CASSANDRA-7284)
 + * Use prepared statements internally (CASSANDRA-6975)
 + * Fix broken paging state with prepared statement (CASSANDRA-7120)
 + * Fix IllegalArgumentException in CqlStorage (CASSANDRA-7287)
 + * Allow nulls/non-existant fields in UDT (CASSANDRA-7206)
 +Merged from 2.0:
   * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
   * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
+  * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
 -
 -2.0.8
   * Always reallocate buffers in HSHA (CASSANDRA-6285)
   * (Hadoop) support authentication in CqlRecordReader (CASSANDRA-7221)
   * (Hadoop) Close java driver Cluster in CQLRR.close (CASSANDRA-7228)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5b314490/src/java/org/apache/cassandra/db/HintedHandOffManager.java
--

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

[marcuse]

Merge branch 'cassandra-2.0' into cassandra-2.1

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/5b314490
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5b314490
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5b314490

Branch: refs/heads/cassandra-2.1
Commit: 5b3144905f08f47e114188647b570450631180a9
Parents: 8cb5058 54618a1
Author: Marcus Eriksson 
Authored: Wed May 28 07:45:24 2014 +0200
Committer: Marcus Eriksson 
Committed: Wed May 28 07:45:24 2014 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/HintedHandOffManager.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5b314490/CHANGES.txt
--
diff --cc CHANGES.txt
index 6240e1e,2b8ce60..a71867a
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,33 -1,12 +1,34 @@@
 -2.0.9
 - * Add missing iso8601 patterns for date strings (6973)
 - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
 - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
 +2.1.0-rc1
 + * Add tab-completion to debian nodetool packaging (CASSANDRA-6421)
 + * Change concurrent_compactors defaults (CASSANDRA-7139)
 + * Add PowerShell Windows launch scripts (CASSANDRA-7001)
 + * Make commitlog archive+restore more robust (CASSANDRA-6974)
 + * Fix marking commitlogsegments clean (CASSANDRA-6959)
 + * Add snapshot "manifest" describing files included (CASSANDRA-6326)
 + * Parallel streaming for sstableloader (CASSANDRA-3668)
 + * Fix bugs in supercolumns handling (CASSANDRA-7138)
 + * Fix ClassClassException on composite dense tables (CASSANDRA-7112)
 + * Cleanup and optimize collation and slice iterators (CASSANDRA-7107)
 + * Upgrade NBHM lib (CASSANDRA-7128)
 + * Optimize netty server (CASSANDRA-6861)
 + * Fix repair hang when given CF does not exist (CASSANDRA-7189)
 + * Allow c* to be shutdown in an embedded mode (CASSANDRA-5635)
 + * Add server side batching to native transport (CASSANDRA-5663)
 + * Make batchlog replay asynchronous (CASSANDRA-6134)
 + * remove unused classes (CASSANDRA-7197)
 + * Limit user types to the keyspace they are defined in (CASSANDRA-6643)
 + * Add validate method to CollectionType (CASSANDRA-7208)
 + * New serialization format for UDT values (CASSANDRA-7209, CASSANDRA-7261)
 + * Fix nodetool netstats (CASSANDRA-7270)
 + * Fix potential ClassCastException in HintedHandoffManager (CASSANDRA-7284)
 + * Use prepared statements internally (CASSANDRA-6975)
 + * Fix broken paging state with prepared statement (CASSANDRA-7120)
 + * Fix IllegalArgumentException in CqlStorage (CASSANDRA-7287)
 + * Allow nulls/non-existant fields in UDT (CASSANDRA-7206)
 +Merged from 2.0:
   * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
   * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
+  * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
 -
 -2.0.8
   * Always reallocate buffers in HSHA (CASSANDRA-6285)
   * (Hadoop) support authentication in CqlRecordReader (CASSANDRA-7221)
   * (Hadoop) Close java driver Cluster in CQLRR.close (CASSANDRA-7228)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5b314490/src/java/org/apache/cassandra/db/HintedHandOffManager.java
--

[1/2] git commit: Make sure we don't try to compact already compacting sstables in HHOM

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 8cb50583d -> 5b3144905


Make sure we don't try to compact already compacting sstables in HHOM

Patch by marcuse; reviewed by jbellis for CASSANDRA-7288


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

Branch: refs/heads/cassandra-2.1
Commit: 54618a1b3eb3783643d450b28e40862f3bed45c3
Parents: 81286b0
Author: Marcus Eriksson 
Authored: Tue May 27 11:12:27 2014 +0200
Committer: Marcus Eriksson 
Committed: Wed May 28 07:43:47 2014 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/HintedHandOffManager.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/54618a1b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6a16cae..2b8ce60 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -4,6 +4,7 @@
  * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
  * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
  * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
+ * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
 
 2.0.8
  * Always reallocate buffers in HSHA (CASSANDRA-6285)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/54618a1b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
--
diff --git a/src/java/org/apache/cassandra/db/HintedHandOffManager.java 
b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
index 13d1bb0..158f6ad 100644
--- a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
+++ b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
@@ -254,7 +254,7 @@ public class HintedHandOffManager implements 
HintedHandOffManagerMBean
 {
 hintStore.forceBlockingFlush();
 ArrayList descriptors = new ArrayList();
-for (SSTable sstable : hintStore.getSSTables())
+for (SSTable sstable : 
hintStore.getDataTracker().getUncompactingSSTables())
 descriptors.add(sstable.descriptor);
 return CompactionManager.instance.submitUserDefined(hintStore, 
descriptors, (int) (System.currentTimeMillis() / 1000));
 }

git commit: Make sure we don't try to compact already compacting sstables in HHOM

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.0 81286b0ca -> 54618a1b3


Make sure we don't try to compact already compacting sstables in HHOM

Patch by marcuse; reviewed by jbellis for CASSANDRA-7288


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

Branch: refs/heads/cassandra-2.0
Commit: 54618a1b3eb3783643d450b28e40862f3bed45c3
Parents: 81286b0
Author: Marcus Eriksson 
Authored: Tue May 27 11:12:27 2014 +0200
Committer: Marcus Eriksson 
Committed: Wed May 28 07:43:47 2014 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/HintedHandOffManager.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/54618a1b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6a16cae..2b8ce60 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -4,6 +4,7 @@
  * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
  * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
  * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
+ * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
 
 2.0.8
  * Always reallocate buffers in HSHA (CASSANDRA-6285)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/54618a1b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
--
diff --git a/src/java/org/apache/cassandra/db/HintedHandOffManager.java 
b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
index 13d1bb0..158f6ad 100644
--- a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
+++ b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
@@ -254,7 +254,7 @@ public class HintedHandOffManager implements 
HintedHandOffManagerMBean
 {
 hintStore.forceBlockingFlush();
 ArrayList descriptors = new ArrayList();
-for (SSTable sstable : hintStore.getSSTables())
+for (SSTable sstable : 
hintStore.getDataTracker().getUncompactingSSTables())
 descriptors.add(sstable.descriptor);
 return CompactionManager.instance.submitUserDefined(hintStore, 
descriptors, (int) (System.currentTimeMillis() / 1000));
 }

[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[Pavel Yaskevich (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010772#comment-14010772
 ] 

Pavel Yaskevich commented on CASSANDRA-7245:


Ref counting seems an obvious culprit to me but [~jasobrown] is reporting that 
CASSANDRA-5663 has the same problem with CASSANDRA-6861 reverted.

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[T Jake Luciani (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010738#comment-14010738
 ] 

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

Good news is I can reproduce now with the following dtest:

{code}

import time

from dtest import Tester, debug
from assertions import assert_unavailable
from tools import (since)

#Run with MAX_HEAP_SIZE=150M HEAP_NEWSIZE=100M
 
class TestNettyTransport(Tester):
@since('2.1')
def reused_bytebuffers_test(self):
debug("Creating a ring")
cluster = self.cluster
cluster.set_configuration_options(values={'concurrent_writes' : 2}, 
batch_commitlog=True)

cluster.populate(2).start()
[node1, node2] = cluster.nodelist()
cluster.start()
 
node1.stress(['write', 'n=10', '-schema', 
'replication(factor=2)','-rate', 'threads=191','-mode','native','cql3', 
'prepared','-col', 'n=fixed(21)', 'size=exp(11..42)'])
node1.stress(['read', 'n=10', '-mode','native','cql3', 'prepared'])
{code}

I've confirmed the issue is the pooled buffer allocator reclaiming the buffers 
too soon. Working on patching the Mutations to keep references to the netty 
frame.

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Updated] (CASSANDRA-7267) Embedded sets in user defined data-types are not updating

[Mikhail Stepura (JIRA)]

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

Mikhail Stepura updated CASSANDRA-7267:
---

Attachment: CASSANDRA-2.1-7267.patch

Patch to work around the problem 

> Embedded sets in user defined data-types are not updating
> -
>
> Key: CASSANDRA-7267
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7267
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Zimmer
>Assignee: Mikhail Stepura
> Fix For: 2.1 rc1
>
> Attachments: CASSANDRA-2.1-7267.patch
>
>
> Hi,
> i just played around with Cassandra 2.1.0 beta2 and i might have found an 
> issue with embedded Sets in User Defined Data Types.
> Here is how i can reproduce it:
> 1.) Create a keyspace "test"
> 2.) Create a table like this:
> {{create table songs (title varchar PRIMARY KEY, band varchar, tags 
> Set);}}
> 3.) Create a udt like this:
> {{create type band_info_type (founded timestamp, members Set, 
> description text);}}
> 4.) Try to insert data:
> {code}
> insert into songs (title, band, band_info, tags) values ('The trooper', 'Iron 
> Maiden', {founded:188694000, members: {'Bruce Dickinson', 'Dave Murray', 
> 'Adrian Smith', 'Janick Gers', 'Steve Harris', 'Nicko McBrain'}, description: 
> 'Pure evil metal'}, {'metal', 'england'});
> {code}
> 5.) Select the data:
> {{select * from songs;}}
> Returns this:
> {code}
> The trooper | Iron Maiden | {founded: '1970-01-03 05:24:54+0100', members: 
> {}, description: 'Pure evil metal'} | {'england', 'metal'}
> {code}
> The embedded data-set seems to empty. I also tried updating a row which also 
> does not seem to work.
> Regards,
> Thomas



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

[jira] [Issue Comment Deleted] (CASSANDRA-7241) Pig test fails on 2.1 branch

[Brandon Williams (JIRA)]

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

Brandon Williams updated CASSANDRA-7241:


Comment: was deleted

(was: If we roll back the cell changes in Pig/Hadoop, those errors should be 
gone. We can create new Hadoop Reader/InputFormat using cell implementation if 
we have to, for hadoop tasks are running in a separate process. I don't see 
using Cell instead of thrift Column really makes much difference)

> Pig test fails on 2.1 branch
> 
>
> Key: CASSANDRA-7241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7241
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Sylvain Lebresne
> Fix For: 2.1 rc1
>
> Attachments: repro-cli.txt, repro-pig.txt
>
>
> run ant pig-test on cassandra-2.1 branch. There are many tests failed. I 
> trace it a little and find out Pig test fails starts from 
> https://github.com/apache/cassandra/commit/362cc05352ec67e707e0ac790732e96a15e63f6b
> commit.
> It looks like storage changes break Pig tests.



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

[jira] [Commented] (CASSANDRA-7241) Pig test fails on 2.1 branch

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010668#comment-14010668
 ] 

Brandon Williams commented on CASSANDRA-7241:
-

That makes sense, but I think we have two problems then, since none of those 
methods appear in the stacktrace I recently posted.

> Pig test fails on 2.1 branch
> 
>
> Key: CASSANDRA-7241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7241
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Sylvain Lebresne
> Fix For: 2.1 rc1
>
> Attachments: repro-cli.txt, repro-pig.txt
>
>
> run ant pig-test on cassandra-2.1 branch. There are many tests failed. I 
> trace it a little and find out Pig test fails starts from 
> https://github.com/apache/cassandra/commit/362cc05352ec67e707e0ac790732e96a15e63f6b
> commit.
> It looks like storage changes break Pig tests.



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

[jira] [Commented] (CASSANDRA-7241) Pig test fails on 2.1 branch

[Alex Liu (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010621#comment-14010621
 ] 

Alex Liu commented on CASSANDRA-7241:
-

I found the following place by peeking into the code

{code}
/** convert a cql column to an object */
private Object cqlColumnToObj(Cell col, CfDef cfDef) throws IOException
{
// standard
Map validators = getValidatorMap(cfDef);
ByteBuffer cellName = col.name().toByteBuffer();
if (validators.get(cellName) == null)
return 
cassandraToObj(getDefaultMarshallers(cfDef).get(MarshallerType.DEFAULT_VALIDATOR),
 col.value());
else
return cassandraToObj(validators.get(cellName), col.value());
}

where ByteBuffer cellName = col.name().toByteBuffer() is not the right way to 
get the column name, It  should use Cell type comparator.
{code}

> Pig test fails on 2.1 branch
> 
>
> Key: CASSANDRA-7241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7241
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Sylvain Lebresne
> Fix For: 2.1 rc1
>
> Attachments: repro-cli.txt, repro-pig.txt
>
>
> run ant pig-test on cassandra-2.1 branch. There are many tests failed. I 
> trace it a little and find out Pig test fails starts from 
> https://github.com/apache/cassandra/commit/362cc05352ec67e707e0ac790732e96a15e63f6b
> commit.
> It looks like storage changes break Pig tests.



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

[jira] [Comment Edited] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010483#comment-14010483
 ] 

Brandon Williams edited comment on CASSANDRA-7307 at 5/28/14 12:56 AM:
---

You're right, RING_DELAY has no effect when replacing because we only sleep for 
load dissemination, which is 60s.  So the only workaround left is to override 
the FD initial value.  Fixed the typo in 4e67631ef8.


was (Author: brandon.williams):
You're right, RING_DELAY has no effect when replacing because we only sleep for 
load dissemination, which is 90s.  So the only workaround left is to override 
the FD initial value.  Fixed the typo in 4e67631ef8.

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Commented] (CASSANDRA-7276) Include keyspace and table names in logs where possible

[J.P. Eiti Kimura (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010523#comment-14010523
 ] 

J.P. Eiti Kimura commented on CASSANDRA-7276:
-

Ops, sorry guys, I think I did a wrong action in this ticket, a blank patch 
submission, sorry for that

> Include keyspace and table names in logs where possible
> ---
>
> Key: CASSANDRA-7276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7276
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Tyler Hobbs
>Priority: Minor
>  Labels: lhf
>
> Most error messages and stacktraces give you no clue as to what keyspace or 
> table was causing the problem.  For example:
> {noformat}
> ERROR [MutationStage:61648] 2014-05-20 12:05:45,145 CassandraDaemon.java 
> (line 198) Exception in thread Thread[MutationStage:61648,5,main]
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Unknown Source)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:63)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:98)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:35)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap$1.compareTo(SnapTreeMap.java:538)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap.attemptUpdate(SnapTreeMap.java:1108)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap.updateUnderRoot(SnapTreeMap.java:1059)
> at edu.stanford.ppl.concurrent.SnapTreeMap.update(SnapTreeMap.java:1023)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap.putIfAbsent(SnapTreeMap.java:985)
> at 
> org.apache.cassandra.db.AtomicSortedColumns$Holder.addColumn(AtomicSortedColumns.java:328)
> at 
> org.apache.cassandra.db.AtomicSortedColumns.addAllWithSizeDelta(AtomicSortedColumns.java:200)
> at org.apache.cassandra.db.Memtable.resolve(Memtable.java:226)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:173)
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:893)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:333)
> at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:206)
> at 
> org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:56)
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> We should try to include info on the keyspace and column family in the error 
> messages or logs whenever possible.  This includes reads, writes, 
> compactions, flushes, repairs, and probably more.



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

[jira] [Commented] (CASSANDRA-7241) Pig test fails on 2.1 branch

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010491#comment-14010491
 ] 

Brandon Williams commented on CASSANDRA-7241:
-

Can you explain why Column vs Cell makes a difference?

> Pig test fails on 2.1 branch
> 
>
> Key: CASSANDRA-7241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7241
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Sylvain Lebresne
> Fix For: 2.1 rc1
>
> Attachments: repro-cli.txt, repro-pig.txt
>
>
> run ant pig-test on cassandra-2.1 branch. There are many tests failed. I 
> trace it a little and find out Pig test fails starts from 
> https://github.com/apache/cassandra/commit/362cc05352ec67e707e0ac790732e96a15e63f6b
> commit.
> It looks like storage changes break Pig tests.



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

[jira] [Commented] (CASSANDRA-7241) Pig test fails on 2.1 branch

[Alex Liu (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010485#comment-14010485
 ] 

Alex Liu commented on CASSANDRA-7241:
-

If we roll back the cell changes in Pig/Hadoop, those errors should be gone. We 
can create new Hadoop Reader/InputFormat using cell implementation if we have 
to, for hadoop tasks are running in a separate process. I don't see using Cell 
instead of thrift Column really makes much difference

> Pig test fails on 2.1 branch
> 
>
> Key: CASSANDRA-7241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7241
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Sylvain Lebresne
> Fix For: 2.1 rc1
>
> Attachments: repro-cli.txt, repro-pig.txt
>
>
> run ant pig-test on cassandra-2.1 branch. There are many tests failed. I 
> trace it a little and find out Pig test fails starts from 
> https://github.com/apache/cassandra/commit/362cc05352ec67e707e0ac790732e96a15e63f6b
> commit.
> It looks like storage changes break Pig tests.



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

[jira] [Commented] (CASSANDRA-7241) Pig test fails on 2.1 branch

[Alex Liu (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010484#comment-14010484
 ] 

Alex Liu commented on CASSANDRA-7241:
-

If we roll back the cell changes in Pig/Hadoop, those errors should be gone. We 
can create new Hadoop Reader/InputFormat using cell implementation if we have 
to, for hadoop tasks are running in a separate process. I don't see using Cell 
instead of thrift Column really makes much difference

> Pig test fails on 2.1 branch
> 
>
> Key: CASSANDRA-7241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7241
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Sylvain Lebresne
> Fix For: 2.1 rc1
>
> Attachments: repro-cli.txt, repro-pig.txt
>
>
> run ant pig-test on cassandra-2.1 branch. There are many tests failed. I 
> trace it a little and find out Pig test fails starts from 
> https://github.com/apache/cassandra/commit/362cc05352ec67e707e0ac790732e96a15e63f6b
> commit.
> It looks like storage changes break Pig tests.



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

[jira] [Commented] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010483#comment-14010483
 ] 

Brandon Williams commented on CASSANDRA-7307:
-

You're right, RING_DELAY has no effect when replacing because we only sleep for 
load dissemination, which is 90s.  So the only workaround left is to override 
the FD initial value.  Fixed the typo in 4e67631ef8.

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

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

[brandonwilliams]

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/707eabdc
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/707eabdc
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/707eabdc

Branch: refs/heads/trunk
Commit: 707eabdc9a4d464408629a571086285dd2c9af5d
Parents: 1b62f3d 8cb5058
Author: Brandon Williams 
Authored: Tue May 27 18:12:43 2014 -0500
Committer: Brandon Williams 
Committed: Tue May 27 18:12:43 2014 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/707eabdc/src/java/org/apache/cassandra/service/StorageService.java
--

[03/10] git commit: fix typo

[brandonwilliams]

fix typo


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

Branch: refs/heads/cassandra-2.1
Commit: 4e67631ef84464ee4a1c141719521e835ddcd529
Parents: de1f7ee
Author: Brandon Williams 
Authored: Tue May 27 18:11:38 2014 -0500
Committer: Brandon Williams 
Committed: Tue May 27 18:11:38 2014 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4e67631e/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 9a6e67a..8e7c073 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -739,7 +739,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 if (existing != null)
 {
 if 
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() > 
(System.currentTimeMillis() - delay))
-throw new 
UnsupportedOperationException("Cannnot replace a live node... ");
+throw new 
UnsupportedOperationException("Cannot replace a live node... ");
 current.add(existing);
 }
 else

[05/10] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

[brandonwilliams]

Merge branch 'cassandra-1.2' into cassandra-2.0

Conflicts:
src/java/org/apache/cassandra/service/StorageService.java


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

Branch: refs/heads/cassandra-2.1
Commit: 81286b0ca2fb5c667d89280b2a7955b2531975c3
Parents: 367c741 4e67631
Author: Brandon Williams 
Authored: Tue May 27 18:12:25 2014 -0500
Committer: Brandon Williams 
Committed: Tue May 27 18:12:25 2014 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/81286b0c/src/java/org/apache/cassandra/service/StorageService.java
--
diff --cc src/java/org/apache/cassandra/service/StorageService.java
index 45bceb5,8e7c073..d261a47
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@@ -768,9 -738,8 +768,9 @@@ public class StorageService extends Not
  InetAddress existing = 
tokenMetadata.getEndpoint(token);
  if (existing != null)
  {
 -if 
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() > 
(System.currentTimeMillis() - delay))
 +long nanoDelay = delay * 100L;
 +if 
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() > 
(System.nanoTime() - nanoDelay))
- throw new 
UnsupportedOperationException("Cannnot replace a live node... ");
+ throw new 
UnsupportedOperationException("Cannot replace a live node... ");
  current.add(existing);
  }
  else

[01/10] git commit: fix typo

[brandonwilliams]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-1.2 de1f7ee1e -> 4e67631ef
  refs/heads/cassandra-2.0 367c74193 -> 81286b0ca
  refs/heads/cassandra-2.1 86b6ec529 -> 8cb50583d
  refs/heads/trunk 1b62f3d39 -> 707eabdc9


fix typo


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

Branch: refs/heads/cassandra-1.2
Commit: 4e67631ef84464ee4a1c141719521e835ddcd529
Parents: de1f7ee
Author: Brandon Williams 
Authored: Tue May 27 18:11:38 2014 -0500
Committer: Brandon Williams 
Committed: Tue May 27 18:11:38 2014 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4e67631e/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 9a6e67a..8e7c073 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -739,7 +739,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 if (existing != null)
 {
 if 
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() > 
(System.currentTimeMillis() - delay))
-throw new 
UnsupportedOperationException("Cannnot replace a live node... ");
+throw new 
UnsupportedOperationException("Cannot replace a live node... ");
 current.add(existing);
 }
 else

[02/10] git commit: fix typo

[brandonwilliams]

fix typo


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

Branch: refs/heads/cassandra-2.0
Commit: 4e67631ef84464ee4a1c141719521e835ddcd529
Parents: de1f7ee
Author: Brandon Williams 
Authored: Tue May 27 18:11:38 2014 -0500
Committer: Brandon Williams 
Committed: Tue May 27 18:11:38 2014 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4e67631e/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 9a6e67a..8e7c073 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -739,7 +739,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 if (existing != null)
 {
 if 
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() > 
(System.currentTimeMillis() - delay))
-throw new 
UnsupportedOperationException("Cannnot replace a live node... ");
+throw new 
UnsupportedOperationException("Cannot replace a live node... ");
 current.add(existing);
 }
 else

[08/10] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1

[brandonwilliams]

Merge branch 'cassandra-2.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/8cb50583
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8cb50583
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8cb50583

Branch: refs/heads/cassandra-2.1
Commit: 8cb50583d42e672d4897061cec53345f9f7839a7
Parents: 86b6ec5 81286b0
Author: Brandon Williams 
Authored: Tue May 27 18:12:34 2014 -0500
Committer: Brandon Williams 
Committed: Tue May 27 18:12:34 2014 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8cb50583/src/java/org/apache/cassandra/service/StorageService.java
--

[09/10] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1

[brandonwilliams]

Merge branch 'cassandra-2.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/8cb50583
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8cb50583
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8cb50583

Branch: refs/heads/trunk
Commit: 8cb50583d42e672d4897061cec53345f9f7839a7
Parents: 86b6ec5 81286b0
Author: Brandon Williams 
Authored: Tue May 27 18:12:34 2014 -0500
Committer: Brandon Williams 
Committed: Tue May 27 18:12:34 2014 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8cb50583/src/java/org/apache/cassandra/service/StorageService.java
--

[06/10] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

[brandonwilliams]

Merge branch 'cassandra-1.2' into cassandra-2.0

Conflicts:
src/java/org/apache/cassandra/service/StorageService.java


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

Branch: refs/heads/cassandra-2.0
Commit: 81286b0ca2fb5c667d89280b2a7955b2531975c3
Parents: 367c741 4e67631
Author: Brandon Williams 
Authored: Tue May 27 18:12:25 2014 -0500
Committer: Brandon Williams 
Committed: Tue May 27 18:12:25 2014 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/81286b0c/src/java/org/apache/cassandra/service/StorageService.java
--
diff --cc src/java/org/apache/cassandra/service/StorageService.java
index 45bceb5,8e7c073..d261a47
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@@ -768,9 -738,8 +768,9 @@@ public class StorageService extends Not
  InetAddress existing = 
tokenMetadata.getEndpoint(token);
  if (existing != null)
  {
 -if 
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() > 
(System.currentTimeMillis() - delay))
 +long nanoDelay = delay * 100L;
 +if 
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() > 
(System.nanoTime() - nanoDelay))
- throw new 
UnsupportedOperationException("Cannnot replace a live node... ");
+ throw new 
UnsupportedOperationException("Cannot replace a live node... ");
  current.add(existing);
  }
  else

[07/10] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

[brandonwilliams]

Merge branch 'cassandra-1.2' into cassandra-2.0

Conflicts:
src/java/org/apache/cassandra/service/StorageService.java


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

Branch: refs/heads/trunk
Commit: 81286b0ca2fb5c667d89280b2a7955b2531975c3
Parents: 367c741 4e67631
Author: Brandon Williams 
Authored: Tue May 27 18:12:25 2014 -0500
Committer: Brandon Williams 
Committed: Tue May 27 18:12:25 2014 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/81286b0c/src/java/org/apache/cassandra/service/StorageService.java
--
diff --cc src/java/org/apache/cassandra/service/StorageService.java
index 45bceb5,8e7c073..d261a47
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@@ -768,9 -738,8 +768,9 @@@ public class StorageService extends Not
  InetAddress existing = 
tokenMetadata.getEndpoint(token);
  if (existing != null)
  {
 -if 
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() > 
(System.currentTimeMillis() - delay))
 +long nanoDelay = delay * 100L;
 +if 
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() > 
(System.nanoTime() - nanoDelay))
- throw new 
UnsupportedOperationException("Cannnot replace a live node... ");
+ throw new 
UnsupportedOperationException("Cannot replace a live node... ");
  current.add(existing);
  }
  else

[04/10] git commit: fix typo

[brandonwilliams]

fix typo


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

Branch: refs/heads/trunk
Commit: 4e67631ef84464ee4a1c141719521e835ddcd529
Parents: de1f7ee
Author: Brandon Williams 
Authored: Tue May 27 18:11:38 2014 -0500
Committer: Brandon Williams 
Committed: Tue May 27 18:11:38 2014 -0500

--
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4e67631e/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 9a6e67a..8e7c073 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -739,7 +739,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 if (existing != null)
 {
 if 
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() > 
(System.currentTimeMillis() - delay))
-throw new 
UnsupportedOperationException("Cannnot replace a live node... ");
+throw new 
UnsupportedOperationException("Cannot replace a live node... ");
 current.add(existing);
 }
 else

[jira] [Comment Edited] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Richard Low (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010478#comment-14010478
 ] 

Richard Low edited comment on CASSANDRA-7307 at 5/27/14 11:09 PM:
--

The 'Cannnot (sic) replace a live node' error came about 1 minute after boot, 
even with a 5 minute RING_DELAY. So I don't think a higher RING_DELAY will work:

INFO [main] 2014-05-23 19:51:16,934 CassandraDaemon.java (line 119) Logging 
initialized
INFO [main] 2014-05-23 19:51:20,038 StorageService.java (line 105) Overriding 
RING_DELAY to 30ms
ERROR [main] 2014-05-23 19:52:25,189 CassandraDaemon.java (line 464) Exception 
encountered during startup
java.lang.UnsupportedOperationException: Cannnot replace a live node... 

I was surprised by this, I expected it to wait for RING_DELAY before getting 
host replacement info. Is this expected behaviour?

(These logs are from 1.2.15)


was (Author: rlow):
The 'Cannnot (sic) replace a live node' error came about 1 minute after boot, 
even with a 5 minute RING_DELAY. So I don't think a higher RING_DELAY will work:

INFO [main] 2014-05-23 19:51:16,934 CassandraDaemon.java (line 119) Logging 
initialized
INFO [main] 2014-05-23 19:51:20,038 StorageService.java (line 105) Overriding 
RING_DELAY to 30ms
ERROR [main] 2014-05-23 19:52:25,189 CassandraDaemon.java (line 464) Exception 
encountered during startup
java.lang.UnsupportedOperationException: Cannnot replace a live node... 

I was surprised by this, I expected it to wait for RING_DELAY before getting 
host replacement info. Is this expected behaviour?

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Commented] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Richard Low (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010478#comment-14010478
 ] 

Richard Low commented on CASSANDRA-7307:


The 'Cannnot (sic) replace a live node' error came about 1 minute after boot, 
even with a 5 minute RING_DELAY. So I don't think a higher RING_DELAY will work:

INFO [main] 2014-05-23 19:51:16,934 CassandraDaemon.java (line 119) Logging 
initialized
INFO [main] 2014-05-23 19:51:20,038 StorageService.java (line 105) Overriding 
RING_DELAY to 30ms
ERROR [main] 2014-05-23 19:52:25,189 CassandraDaemon.java (line 464) Exception 
encountered during startup
java.lang.UnsupportedOperationException: Cannnot replace a live node... 

I was surprised by this, I expected it to wait for RING_DELAY before getting 
host replacement info. Is this expected behaviour?

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Commented] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010466#comment-14010466
 ] 

Brandon Williams commented on CASSANDRA-7307:
-

You'd have to set it to 10 minutes or so, since that's how long failure 
detection is taking :(

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Commented] (CASSANDRA-7308) Dropped keyspace causes issues later

[Joaquin Casares (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010468#comment-14010468
 ] 

Joaquin Casares commented on CASSANDRA-7308:


ok, I'll do that then until 2.1. Thanks!

> Dropped keyspace causes issues later
> 
>
> Key: CASSANDRA-7308
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7308
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joaquin Casares
>  Labels: datastax_qa
>
> I had a keyspace that was accepting writes and was able to query the keyspace 
> via cqlsh. I re-ran my test application that drops the keyspace if it exists 
> then creates the keyspace and wrote some more. This time, however, any select 
> request via cqlsh breaks with a `Request did not complete within 
> rpc_timeout.`.
> This was seen in the system.log:
> {CODE}
> ERROR [ReadStage:61096] 2014-05-27 17:21:39,995 CassandraDaemon.java (line 
> 198) Exception in thread Thread[ReadStage:61096,5,main]
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1927)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:59)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1362)
>   at 
> org.apache.cassandra.io.sstable.SSTableScanner.(SSTableScanner.java:67)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReader.java:1147)
>   at 
> org.apache.cassandra.db.RowIteratorFactory.getIterator(RowIteratorFactory.java:69)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getSequentialIterator(ColumnFamilyStore.java:1579)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1699)
>   at 
> org.apache.cassandra.db.RangeSliceCommand.executeLocally(RangeSliceCommand.java:137)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1381)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1923)
>   ... 3 more
> Caused by: java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at java.io.RandomAccessFile.open(Native Method)
>   at java.io.RandomAccessFile.(RandomAccessFile.java:241)
>   at 
> org.apache.cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:58)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.(CompressedRandomAccessReader.java:76)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:55)
>   ... 12 more
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,810 ColumnFamilyStore.java 
> (line 787) Enqueuing flush of Memtable-compactions_in_progress@46337516(0/0 
> serialized/live bytes, 1 ops)
>  WARN [MemoryMeter:1] 2014-05-27 17:21:42,810 Memtable.java (line 470) 
> setting live ratio to maximum of 64.0 instead of Infinity
>  INFO [MemoryMeter:1] 2014-05-27 17:21:42,811 Memtable.java (line 481) 
> CFS(Keyspace='system', ColumnFamily='compactions_in_progress') liveRatio is 
> 64.0 (just-counted was 64.0).  calculation took 0ms for 0 cells
>  INFO [FlushWriter:92] 2014-05-27 17:21:42,811 Memtable.java (line 363) 
> Writing Memtable-compactions_in_progress@46337516(0/0 serialized/live bytes, 
> 1 ops)
>  INFO [FlushWriter:92] 2014-05-27 17:21:42,817 Memtable.java (line 403) 
> Completed flushing 
> /var/lib/cassandra/data/system/compactions_in_progress/system-compactions_in_progress-jb-51-Data.db
>  (42 bytes) for commitlog position ReplayPosition(segmentId=1400882649502, 
> position=5391795)
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,819 CompactionTask.java 
> (line 275) Compacted 4 sstables to 
> [/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-87,]. 
>  56,962,552 bytes to 56,961,531 (~99% of original) in 77,261ms = 
> 0.703107MB/s.  5 total partitions merged to 2.  Partition merge counts were 
> {1:1, 4:1, }
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,820 ColumnFamilyStore.java 
> (l

[jira] [Resolved] (CASSANDRA-7308) Dropped keyspace causes issues later

[Brandon Williams (JIRA)]

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

Brandon Williams resolved CASSANDRA-7308.
-

Resolution: Invalid

The short answer here is "don't do that" and the long one is CASSANDRA-5202.  
If you aren't changing the schema but just trying to empty the ks/cf, use 
truncate instead.

> Dropped keyspace causes issues later
> 
>
> Key: CASSANDRA-7308
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7308
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joaquin Casares
>  Labels: datastax_qa
>
> I had a keyspace that was accepting writes and was able to query the keyspace 
> via cqlsh. I re-ran my test application that drops the keyspace if it exists 
> then creates the keyspace and wrote some more. This time, however, any select 
> request via cqlsh breaks with a `Request did not complete within 
> rpc_timeout.`.
> This was seen in the system.log:
> {CODE}
> ERROR [ReadStage:61096] 2014-05-27 17:21:39,995 CassandraDaemon.java (line 
> 198) Exception in thread Thread[ReadStage:61096,5,main]
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1927)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:59)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1362)
>   at 
> org.apache.cassandra.io.sstable.SSTableScanner.(SSTableScanner.java:67)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReader.java:1147)
>   at 
> org.apache.cassandra.db.RowIteratorFactory.getIterator(RowIteratorFactory.java:69)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getSequentialIterator(ColumnFamilyStore.java:1579)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1699)
>   at 
> org.apache.cassandra.db.RangeSliceCommand.executeLocally(RangeSliceCommand.java:137)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1381)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1923)
>   ... 3 more
> Caused by: java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at java.io.RandomAccessFile.open(Native Method)
>   at java.io.RandomAccessFile.(RandomAccessFile.java:241)
>   at 
> org.apache.cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:58)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.(CompressedRandomAccessReader.java:76)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:55)
>   ... 12 more
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,810 ColumnFamilyStore.java 
> (line 787) Enqueuing flush of Memtable-compactions_in_progress@46337516(0/0 
> serialized/live bytes, 1 ops)
>  WARN [MemoryMeter:1] 2014-05-27 17:21:42,810 Memtable.java (line 470) 
> setting live ratio to maximum of 64.0 instead of Infinity
>  INFO [MemoryMeter:1] 2014-05-27 17:21:42,811 Memtable.java (line 481) 
> CFS(Keyspace='system', ColumnFamily='compactions_in_progress') liveRatio is 
> 64.0 (just-counted was 64.0).  calculation took 0ms for 0 cells
>  INFO [FlushWriter:92] 2014-05-27 17:21:42,811 Memtable.java (line 363) 
> Writing Memtable-compactions_in_progress@46337516(0/0 serialized/live bytes, 
> 1 ops)
>  INFO [FlushWriter:92] 2014-05-27 17:21:42,817 Memtable.java (line 403) 
> Completed flushing 
> /var/lib/cassandra/data/system/compactions_in_progress/system-compactions_in_progress-jb-51-Data.db
>  (42 bytes) for commitlog position ReplayPosition(segmentId=1400882649502, 
> position=5391795)
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,819 CompactionTask.java 
> (line 275) Compacted 4 sstables to 
> [/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-87,]. 
>  56,962,552 bytes to 56,961,531 (~99% of original) in 77,261ms = 
> 0.703107MB/s.  5 total partitions merged to 2.  Partition merge counts wer

[jira] [Commented] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Richard Low (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010462#comment-14010462
 ] 

Richard Low commented on CASSANDRA-7307:


For host replacement, I tried increasing RING_DELAY to 5 minutes and got 
'java.lang.UnsupportedOperationException: Cannnot replace a live node... '. So 
I don't think increasing RING_DELAY is a valid workaround, at least for host 
replacement.

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Commented] (CASSANDRA-7308) Dropped keyspace causes issues later

[Joaquin Casares (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010456#comment-14010456
 ] 

Joaquin Casares commented on CASSANDRA-7308:


Yes, I'm recreating the keyspace. I'll edit the description to include this.

> Dropped keyspace causes issues later
> 
>
> Key: CASSANDRA-7308
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7308
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joaquin Casares
>  Labels: datastax_qa
>
> I had a keyspace that was accepting writes and was able to query the keyspace 
> via cqlsh. I re-ran my test application that drops the keyspace if it exists 
> and wrote some more. This time, however, any select request via cqlsh breaks 
> with a `Request did not complete within rpc_timeout.`.
> This was seen in the system.log:
> {CODE}
> ERROR [ReadStage:61096] 2014-05-27 17:21:39,995 CassandraDaemon.java (line 
> 198) Exception in thread Thread[ReadStage:61096,5,main]
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1927)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:59)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1362)
>   at 
> org.apache.cassandra.io.sstable.SSTableScanner.(SSTableScanner.java:67)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReader.java:1147)
>   at 
> org.apache.cassandra.db.RowIteratorFactory.getIterator(RowIteratorFactory.java:69)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getSequentialIterator(ColumnFamilyStore.java:1579)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1699)
>   at 
> org.apache.cassandra.db.RangeSliceCommand.executeLocally(RangeSliceCommand.java:137)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1381)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1923)
>   ... 3 more
> Caused by: java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at java.io.RandomAccessFile.open(Native Method)
>   at java.io.RandomAccessFile.(RandomAccessFile.java:241)
>   at 
> org.apache.cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:58)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.(CompressedRandomAccessReader.java:76)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:55)
>   ... 12 more
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,810 ColumnFamilyStore.java 
> (line 787) Enqueuing flush of Memtable-compactions_in_progress@46337516(0/0 
> serialized/live bytes, 1 ops)
>  WARN [MemoryMeter:1] 2014-05-27 17:21:42,810 Memtable.java (line 470) 
> setting live ratio to maximum of 64.0 instead of Infinity
>  INFO [MemoryMeter:1] 2014-05-27 17:21:42,811 Memtable.java (line 481) 
> CFS(Keyspace='system', ColumnFamily='compactions_in_progress') liveRatio is 
> 64.0 (just-counted was 64.0).  calculation took 0ms for 0 cells
>  INFO [FlushWriter:92] 2014-05-27 17:21:42,811 Memtable.java (line 363) 
> Writing Memtable-compactions_in_progress@46337516(0/0 serialized/live bytes, 
> 1 ops)
>  INFO [FlushWriter:92] 2014-05-27 17:21:42,817 Memtable.java (line 403) 
> Completed flushing 
> /var/lib/cassandra/data/system/compactions_in_progress/system-compactions_in_progress-jb-51-Data.db
>  (42 bytes) for commitlog position ReplayPosition(segmentId=1400882649502, 
> position=5391795)
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,819 CompactionTask.java 
> (line 275) Compacted 4 sstables to 
> [/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-87,]. 
>  56,962,552 bytes to 56,961,531 (~99% of original) in 77,261ms = 
> 0.703107MB/s.  5 total partitions merged to 2.  Partition merge counts were 
> {1:1, 4:1, }
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,820 ColumnFamilyStore.jav

[jira] [Updated] (CASSANDRA-7308) Dropped keyspace causes issues later

[Joaquin Casares (JIRA)]

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

Joaquin Casares updated CASSANDRA-7308:
---

Description: 
I had a keyspace that was accepting writes and was able to query the keyspace 
via cqlsh. I re-ran my test application that drops the keyspace if it exists 
then creates the keyspace and wrote some more. This time, however, any select 
request via cqlsh breaks with a `Request did not complete within rpc_timeout.`.

This was seen in the system.log:

{CODE}
ERROR [ReadStage:61096] 2014-05-27 17:21:39,995 CassandraDaemon.java (line 198) 
Exception in thread Thread[ReadStage:61096,5,main]
java.lang.RuntimeException: java.lang.RuntimeException: 
java.io.FileNotFoundException: 
/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
 (No such file or directory)
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1927)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: 
/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
 (No such file or directory)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:59)
at 
org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1362)
at 
org.apache.cassandra.io.sstable.SSTableScanner.(SSTableScanner.java:67)
at 
org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReader.java:1147)
at 
org.apache.cassandra.db.RowIteratorFactory.getIterator(RowIteratorFactory.java:69)
at 
org.apache.cassandra.db.ColumnFamilyStore.getSequentialIterator(ColumnFamilyStore.java:1579)
at 
org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1699)
at 
org.apache.cassandra.db.RangeSliceCommand.executeLocally(RangeSliceCommand.java:137)
at 
org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1381)
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1923)
... 3 more
Caused by: java.io.FileNotFoundException: 
/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
 (No such file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.(RandomAccessFile.java:241)
at 
org.apache.cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:58)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.(CompressedRandomAccessReader.java:76)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:55)
... 12 more
 INFO [CompactionExecutor:708] 2014-05-27 17:21:42,810 ColumnFamilyStore.java 
(line 787) Enqueuing flush of Memtable-compactions_in_progress@46337516(0/0 
serialized/live bytes, 1 ops)
 WARN [MemoryMeter:1] 2014-05-27 17:21:42,810 Memtable.java (line 470) setting 
live ratio to maximum of 64.0 instead of Infinity
 INFO [MemoryMeter:1] 2014-05-27 17:21:42,811 Memtable.java (line 481) 
CFS(Keyspace='system', ColumnFamily='compactions_in_progress') liveRatio is 
64.0 (just-counted was 64.0).  calculation took 0ms for 0 cells
 INFO [FlushWriter:92] 2014-05-27 17:21:42,811 Memtable.java (line 363) Writing 
Memtable-compactions_in_progress@46337516(0/0 serialized/live bytes, 1 ops)
 INFO [FlushWriter:92] 2014-05-27 17:21:42,817 Memtable.java (line 403) 
Completed flushing 
/var/lib/cassandra/data/system/compactions_in_progress/system-compactions_in_progress-jb-51-Data.db
 (42 bytes) for commitlog position ReplayPosition(segmentId=1400882649502, 
position=5391795)
 INFO [CompactionExecutor:708] 2014-05-27 17:21:42,819 CompactionTask.java 
(line 275) Compacted 4 sstables to 
[/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-87,].  
56,962,552 bytes to 56,961,531 (~99% of original) in 77,261ms = 0.703107MB/s.  
5 total partitions merged to 2.  Partition merge counts were {1:1, 4:1, }
 INFO [CompactionExecutor:708] 2014-05-27 17:21:42,820 ColumnFamilyStore.java 
(line 787) Enqueuing flush of 
Memtable-compactions_in_progress@1777281623(179/3463 serialized/live bytes, 9 
ops)
 INFO [MemoryMeter:1] 2014-05-27 17:21:42,820 Memtable.java (line 481) 
CFS(Keyspace='system', ColumnFamily='compactions_in_progress') liveRatio is 
17.862604748603353 (just-counted was 16.374301675977655).  calculation took 0ms 
for 7 cells
 INFO [FlushWriter:92] 2014-05-27 17:21:42,820 Memtable.java (line 363) Writing 
Memtable-compactions_in_progress@1777281623(179/3197 serialized/live bytes, 9 
ops)
 INFO [Flu

[jira] [Commented] (CASSANDRA-7308) Dropped keyspace causes issues later

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010451#comment-14010451
 ] 

Brandon Williams commented on CASSANDRA-7308:
-

Are you dropping an recreating the keyspace?

> Dropped keyspace causes issues later
> 
>
> Key: CASSANDRA-7308
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7308
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joaquin Casares
>  Labels: datastax_qa
>
> I had a keyspace that was accepting writes and was able to query the keyspace 
> via cqlsh. I re-ran my test application that drops the keyspace if it exists 
> and wrote some more. This time, however, any select request via cqlsh breaks 
> with a `Request did not complete within rpc_timeout.`.
> This was seen in the system.log:
> {CODE}
> ERROR [ReadStage:61096] 2014-05-27 17:21:39,995 CassandraDaemon.java (line 
> 198) Exception in thread Thread[ReadStage:61096,5,main]
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1927)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:59)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1362)
>   at 
> org.apache.cassandra.io.sstable.SSTableScanner.(SSTableScanner.java:67)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReader.java:1147)
>   at 
> org.apache.cassandra.db.RowIteratorFactory.getIterator(RowIteratorFactory.java:69)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getSequentialIterator(ColumnFamilyStore.java:1579)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1699)
>   at 
> org.apache.cassandra.db.RangeSliceCommand.executeLocally(RangeSliceCommand.java:137)
>   at 
> org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1381)
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1923)
>   ... 3 more
> Caused by: java.io.FileNotFoundException: 
> /var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
>  (No such file or directory)
>   at java.io.RandomAccessFile.open(Native Method)
>   at java.io.RandomAccessFile.(RandomAccessFile.java:241)
>   at 
> org.apache.cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:58)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.(CompressedRandomAccessReader.java:76)
>   at 
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:55)
>   ... 12 more
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,810 ColumnFamilyStore.java 
> (line 787) Enqueuing flush of Memtable-compactions_in_progress@46337516(0/0 
> serialized/live bytes, 1 ops)
>  WARN [MemoryMeter:1] 2014-05-27 17:21:42,810 Memtable.java (line 470) 
> setting live ratio to maximum of 64.0 instead of Infinity
>  INFO [MemoryMeter:1] 2014-05-27 17:21:42,811 Memtable.java (line 481) 
> CFS(Keyspace='system', ColumnFamily='compactions_in_progress') liveRatio is 
> 64.0 (just-counted was 64.0).  calculation took 0ms for 0 cells
>  INFO [FlushWriter:92] 2014-05-27 17:21:42,811 Memtable.java (line 363) 
> Writing Memtable-compactions_in_progress@46337516(0/0 serialized/live bytes, 
> 1 ops)
>  INFO [FlushWriter:92] 2014-05-27 17:21:42,817 Memtable.java (line 403) 
> Completed flushing 
> /var/lib/cassandra/data/system/compactions_in_progress/system-compactions_in_progress-jb-51-Data.db
>  (42 bytes) for commitlog position ReplayPosition(segmentId=1400882649502, 
> position=5391795)
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,819 CompactionTask.java 
> (line 275) Compacted 4 sstables to 
> [/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-87,]. 
>  56,962,552 bytes to 56,961,531 (~99% of original) in 77,261ms = 
> 0.703107MB/s.  5 total partitions merged to 2.  Partition merge counts were 
> {1:1, 4:1, }
>  INFO [CompactionExecutor:708] 2014-05-27 17:21:42,820 ColumnFamilyStore.java 
> (line 787) Enqueuing flus

[jira] [Created] (CASSANDRA-7309) Explicit limit for maximum number of Thrift connections

[Rick Branson (JIRA)]

Rick Branson created CASSANDRA-7309:
---

 Summary: Explicit limit for maximum number of Thrift connections
 Key: CASSANDRA-7309
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7309
 Project: Cassandra
  Issue Type: Improvement
Reporter: Rick Branson


The 'sync' Thrift server gets this by way of "rpc_max_threads" in the YAML 
file, but the 'hsha' server misses out here. Not having a limit here is 
dangerous because it allows badly behaving clients to use up all the file 
handles and prevents Cassandra from opening any files, leaving the daemon dead 
in the water.



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

[jira] [Created] (CASSANDRA-7308) Dropped keyspace causes issues later

[Joaquin Casares (JIRA)]

Joaquin Casares created CASSANDRA-7308:
--

 Summary: Dropped keyspace causes issues later
 Key: CASSANDRA-7308
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7308
 Project: Cassandra
  Issue Type: Bug
Reporter: Joaquin Casares


I had a keyspace that was accepting writes and was able to query the keyspace 
via cqlsh. I re-ran my test application that drops the keyspace if it exists 
and wrote some more. This time, however, any select request via cqlsh breaks 
with a `Request did not complete within rpc_timeout.`.

This was seen in the system.log:

{CODE}
ERROR [ReadStage:61096] 2014-05-27 17:21:39,995 CassandraDaemon.java (line 198) 
Exception in thread Thread[ReadStage:61096,5,main]
java.lang.RuntimeException: java.lang.RuntimeException: 
java.io.FileNotFoundException: 
/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
 (No such file or directory)
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1927)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: 
/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
 (No such file or directory)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:59)
at 
org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1362)
at 
org.apache.cassandra.io.sstable.SSTableScanner.(SSTableScanner.java:67)
at 
org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReader.java:1147)
at 
org.apache.cassandra.db.RowIteratorFactory.getIterator(RowIteratorFactory.java:69)
at 
org.apache.cassandra.db.ColumnFamilyStore.getSequentialIterator(ColumnFamilyStore.java:1579)
at 
org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1699)
at 
org.apache.cassandra.db.RangeSliceCommand.executeLocally(RangeSliceCommand.java:137)
at 
org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1381)
at 
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1923)
... 3 more
Caused by: java.io.FileNotFoundException: 
/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-36-Data.db
 (No such file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.(RandomAccessFile.java:241)
at 
org.apache.cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:58)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.(CompressedRandomAccessReader.java:76)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:55)
... 12 more
 INFO [CompactionExecutor:708] 2014-05-27 17:21:42,810 ColumnFamilyStore.java 
(line 787) Enqueuing flush of Memtable-compactions_in_progress@46337516(0/0 
serialized/live bytes, 1 ops)
 WARN [MemoryMeter:1] 2014-05-27 17:21:42,810 Memtable.java (line 470) setting 
live ratio to maximum of 64.0 instead of Infinity
 INFO [MemoryMeter:1] 2014-05-27 17:21:42,811 Memtable.java (line 481) 
CFS(Keyspace='system', ColumnFamily='compactions_in_progress') liveRatio is 
64.0 (just-counted was 64.0).  calculation took 0ms for 0 cells
 INFO [FlushWriter:92] 2014-05-27 17:21:42,811 Memtable.java (line 363) Writing 
Memtable-compactions_in_progress@46337516(0/0 serialized/live bytes, 1 ops)
 INFO [FlushWriter:92] 2014-05-27 17:21:42,817 Memtable.java (line 403) 
Completed flushing 
/var/lib/cassandra/data/system/compactions_in_progress/system-compactions_in_progress-jb-51-Data.db
 (42 bytes) for commitlog position ReplayPosition(segmentId=1400882649502, 
position=5391795)
 INFO [CompactionExecutor:708] 2014-05-27 17:21:42,819 CompactionTask.java 
(line 275) Compacted 4 sstables to 
[/var/lib/cassandra/data/weathercql/historical/weathercql-historical-jb-87,].  
56,962,552 bytes to 56,961,531 (~99% of original) in 77,261ms = 0.703107MB/s.  
5 total partitions merged to 2.  Partition merge counts were {1:1, 4:1, }
 INFO [CompactionExecutor:708] 2014-05-27 17:21:42,820 ColumnFamilyStore.java 
(line 787) Enqueuing flush of 
Memtable-compactions_in_progress@1777281623(179/3463 serialized/live bytes, 9 
ops)
 INFO [MemoryMeter:1] 2014-05-27 17:21:42,820 Memtable.java (line 481) 
CFS(Keyspace='system', ColumnFamily='compactions_in_progress') liveRatio is 
17.862604748603353 (just-counted was 16.374301675977655).  calculation took 0ms 
for 7 cells
 INFO [FlushWriter:92] 2014-05-27 17:21:42,820 Memtable.java (line 363) Writing

[jira] [Commented] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010428#comment-14010428
 ] 

Brandon Williams commented on CASSANDRA-7307:
-

I'll note this is especially pernicious for replacement, since the time to mark 
the node down will always be longer than RING_DELAY, and overriding RING_DELAY 
to be long enough is annoying.  Here's how long it takes with the initial value 
set to 3000ms:

{noformat}
 INFO 22:22:06,270 InetAddress /10.208.8.63 is now UP
 INFO 22:23:01,978 InetAddress /10.208.8.63 is now DOWN
{noformat}

Which is better, but still exceeds RING_DELAY, though overriding that to one 
minute or so is much more reasonable.

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Commented] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010403#comment-14010403
 ] 

Brandon Williams commented on CASSANDRA-7307:
-

I was just looking at this.. here are my results:

{noformat}
 INFO 21:58:45,820 Node /10.208.8.63 state jump to normal
 INFO 22:07:58,880 InetAddress /10.208.8.63 is now DOWN
{noformat}

I'm 100% sure the cause of this is CASSANDRA-6385.  Luckily, after 
CASSANDRA-4375 you can override this.  Unluckily, you have to apply a two liner 
from CASSANDRA-6751 because of stupid static initialization.  We should, 
perhaps, revisit our motivation for CASSANDRA-6385 and make the default much 
lower (for the common case) and let people who are using 1000 node clusters 
with vnodes perform the override instead.

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Updated] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Brandon Williams (JIRA)]

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

Brandon Williams updated CASSANDRA-7307:


Fix Version/s: 1.2.17

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Updated] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Brandon Williams (JIRA)]

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

Brandon Williams updated CASSANDRA-7307:


Since Version: 1.2.13  (was: 1.2.15)

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Comment Edited] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010403#comment-14010403
 ] 

Brandon Williams edited comment on CASSANDRA-7307 at 5/27/14 10:16 PM:
---

I was just looking at this.. here are my results:

{noformat}
 INFO 21:58:45,820 Node /10.208.8.63 state jump to normal
 INFO 22:07:58,880 InetAddress /10.208.8.63 is now DOWN
{noformat}

I'm 100% sure the cause of this is CASSANDRA-6385.  Luckily, after 
CASSANDRA-4375 you can override this.  Unluckily, you have to apply a two liner 
from CASSANDRA-6751 because of stupid static initialization.  We should, 
perhaps, revisit our motivation for CASSANDRA-6385 and make the default much 
lower (for the common case) and let people who are using 1000 node clusters 
with vnodes perform the override instead.  WDYT [~jbellis]?


was (Author: brandon.williams):
I was just looking at this.. here are my results:

{noformat}
 INFO 21:58:45,820 Node /10.208.8.63 state jump to normal
 INFO 22:07:58,880 InetAddress /10.208.8.63 is now DOWN
{noformat}

I'm 100% sure the cause of this is CASSANDRA-6385.  Luckily, after 
CASSANDRA-4375 you can override this.  Unluckily, you have to apply a two liner 
from CASSANDRA-6751 because of stupid static initialization.  We should, 
perhaps, revisit our motivation for CASSANDRA-6385 and make the default much 
lower (for the common case) and let people who are using 1000 node clusters 
with vnodes perform the override instead.

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
> Fix For: 1.2.17
>
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Comment Edited] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010389#comment-14010389
 ] 

Benedict edited comment on CASSANDRA-7245 at 5/27/14 10:13 PM:
---

To answer your question [~xedin], with RF>1 it's possible for the surmised bug 
to be hit without timeouts - if the write stage finishes applying its mutation 
before the OTC has forwarded the data to the next node, and we're running with 
CL.ONE (stress default), then the other node can get the corrupted data. If the 
other node was in the middle of a flush/GC, the OTC could easily be backed up 
causing this bug to present very commonly. I believe Jason hit this bug much 
more easily with RF=2, so this would explain everything.

FTR, I think it is unlikely 5663 has anything to do with this.


was (Author: benedict):
To answer your question [~xedin], with RF>1 it's possible for the surmised bug 
to be hit without timeouts - if the write stage finishes applying its mutation 
before the OTC has forwarded the data to the next node, and we're running with 
CL.ONE (stress default), then the other node can get the corrupted data. If the 
other node was in the middle of a flush/GC, the OTC could easily be backed up 
causing this bug to present very commonly. I believe Jason hit this bug much 
more easily with RF=2, so this would explain everything.

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010389#comment-14010389
 ] 

Benedict commented on CASSANDRA-7245:
-

To answer your question [~xedin], with RF>1 it's possible for the surmised bug 
to be hit without timeouts - if the write stage finishes applying its mutation 
before the OTC has forwarded the data to the next node, and we're running with 
CL.ONE (stress default), then the other node can get the corrupted data. If the 
other node was in the middle of a flush/GC, the OTC could easily be backed up 
causing this bug to present very commonly. I believe Jason hit this bug much 
more easily with RF=2, so this would explain everything.

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Assigned] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Brandon Williams (JIRA)]

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

Brandon Williams reassigned CASSANDRA-7307:
---

Assignee: Brandon Williams

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>Assignee: Brandon Williams
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Updated] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Richard Low (JIRA)]

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

Richard Low updated CASSANDRA-7307:
---

Description: 
When doing a node replacement when other nodes are down we see the down nodes 
marked as up for about 10 minutes. This means requests are routed to the dead 
nodes causing timeouts. It also means replacing a node when multiple nodes from 
a replica set is extremely difficult - the node usually tries to stream from a 
dead node and the replacement fails.

This isn't limited to host replacement. I did a simple test:

1. Create a 2 node cluster
2. Kill node 2
3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
don't think this is significant)

The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:

{code}
INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
initialized
INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
/127.0.0.2 is now part of the cluster
INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
InetAddress /127.0.0.2 is now UP
INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
InetAddress /127.0.0.2 is now DOWN
{code}

I reproduced on 1.2.15 and 1.2.16.

  was:
When doing a node replacement when other nodes are down we see the down nodes 
marked as up for about 10 minutes. This means requests are routed to the dead 
nodes causing timeouts. It also means replacing a node when multiple nodes from 
a replica set is extremely difficult - the node usually tries to stream from a 
dead node and the replacement fails.

This isn't limited to host replacement. I did a simple test:

1. Create a 2 node cluster
2. Kill node 2
3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
don't think this is significant)

The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:

{code}
INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
initialized
INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
/127.0.0.2 is now part of the cluster
INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
InetAddress /127.0.0.2 is now UP
INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
InetAddress /127.0.0.2 is now DOWN
{code}

This repro is on 1.2.16.


> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> I reproduced on 1.2.15 and 1.2.16.



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

[jira] [Updated] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Richard Low (JIRA)]

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

Richard Low updated CASSANDRA-7307:
---

Since Version: 1.2.15  (was: 1.2.16)

> New nodes mark dead nodes as up for 10 minutes
> --
>
> Key: CASSANDRA-7307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Low
>
> When doing a node replacement when other nodes are down we see the down nodes 
> marked as up for about 10 minutes. This means requests are routed to the dead 
> nodes causing timeouts. It also means replacing a node when multiple nodes 
> from a replica set is extremely difficult - the node usually tries to stream 
> from a dead node and the replacement fails.
> This isn't limited to host replacement. I did a simple test:
> 1. Create a 2 node cluster
> 2. Kill node 2
> 3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
> don't think this is significant)
> The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:
> {code}
> INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
> initialized
> INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
> /127.0.0.2 is now part of the cluster
> INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
> InetAddress /127.0.0.2 is now UP
> INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
> InetAddress /127.0.0.2 is now DOWN
> {code}
> This repro is on 1.2.16.



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

[jira] [Created] (CASSANDRA-7307) New nodes mark dead nodes as up for 10 minutes

[Richard Low (JIRA)]

Richard Low created CASSANDRA-7307:
--

 Summary: New nodes mark dead nodes as up for 10 minutes
 Key: CASSANDRA-7307
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7307
 Project: Cassandra
  Issue Type: Bug
Reporter: Richard Low


When doing a node replacement when other nodes are down we see the down nodes 
marked as up for about 10 minutes. This means requests are routed to the dead 
nodes causing timeouts. It also means replacing a node when multiple nodes from 
a replica set is extremely difficult - the node usually tries to stream from a 
dead node and the replacement fails.

This isn't limited to host replacement. I did a simple test:

1. Create a 2 node cluster
2. Kill node 2
3. Start a 3rd node with a unique token (I used auto_bootstrap=false but I 
don't think this is significant)

The 3rd node lists node 2 (127.0.0.2) as up for almost 10 minutes:

{code}
INFO [main] 2014-05-27 14:28:24,753 CassandraDaemon.java (line 119) Logging 
initialized
INFO [GossipStage:1] 2014-05-27 14:28:31,492 Gossiper.java (line 843) Node 
/127.0.0.2 is now part of the cluster
INFO [GossipStage:1] 2014-05-27 14:28:31,495 Gossiper.java (line 809) 
InetAddress /127.0.0.2 is now UP
INFO [GossipTasks:1] 2014-05-27 14:37:44,526 Gossiper.java (line 823) 
InetAddress /127.0.0.2 is now DOWN
{code}

This repro is on 1.2.16.



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

[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[Jason Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010355#comment-14010355
 ] 

Jason Brown commented on CASSANDRA-7245:


seeing the corruption with 6861 and without 5663.

So, in short, the presence of either patch causes the corruption.

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[Jason Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010331#comment-14010331
 ] 

Jason Brown commented on CASSANDRA-7245:


Err, hold on - just ran a test with 6881 and no 5663, and saw the corruption 
(again, rather quickly). Let me try one more time, but with 6861 and without 
5663.

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Updated] (CASSANDRA-7241) Pig test fails on 2.1 branch

[Brandon Williams (JIRA)]

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

Brandon Williams updated CASSANDRA-7241:


Attachment: repro-pig.txt
repro-cli.txt

Went ahead and attached the files.

> Pig test fails on 2.1 branch
> 
>
> Key: CASSANDRA-7241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7241
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Sylvain Lebresne
> Fix For: 2.1 rc1
>
> Attachments: repro-cli.txt, repro-pig.txt
>
>
> run ant pig-test on cassandra-2.1 branch. There are many tests failed. I 
> trace it a little and find out Pig test fails starts from 
> https://github.com/apache/cassandra/commit/362cc05352ec67e707e0ac790732e96a15e63f6b
> commit.
> It looks like storage changes break Pig tests.



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

[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[T Jake Luciani (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010321#comment-14010321
 ] 

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

I'm quite sure the issue is 6861 so let me post a patch for you to test

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Assigned] (CASSANDRA-7241) Pig test fails on 2.1 branch

[Brandon Williams (JIRA)]

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

Brandon Williams reassigned CASSANDRA-7241:
---

Assignee: Sylvain Lebresne  (was: Brandon Williams)

> Pig test fails on 2.1 branch
> 
>
> Key: CASSANDRA-7241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7241
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Sylvain Lebresne
> Fix For: 2.1 rc1
>
>
> run ant pig-test on cassandra-2.1 branch. There are many tests failed. I 
> trace it a little and find out Pig test fails starts from 
> https://github.com/apache/cassandra/commit/362cc05352ec67e707e0ac790732e96a15e63f6b
> commit.
> It looks like storage changes break Pig tests.



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

[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[Jason Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010295#comment-14010295
 ] 

Jason Brown commented on CASSANDRA-7245:


Will do, but requires a bit of finesse as 5663 depends on some of the changes 
introduced in 6861. Just want to ensure those aren't very interesting changes.

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Commented] (CASSANDRA-7241) Pig test fails on 2.1 branch

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010299#comment-14010299
 ] 

Brandon Williams commented on CASSANDRA-7241:
-

So, I took a different tack and ignored these errors, and instead focused on 
ThriftColumnFamilyDataTypeTest, which fails with:

{noformat}
[junit] Testcase: 
testCassandraStorageDataType(org.apache.cassandra.pig.ThriftColumnFamilyDataTypeTest):
Caused an ERROR
[junit] org.apache.pig.data.DefaultDataBag cannot be cast to 
org.apache.pig.data.Tuple
[junit] java.lang.ClassCastException: org.apache.pig.data.DefaultDataBag 
cannot be cast to org.apache.pig.data.Tuple
[junit] at 
org.apache.cassandra.pig.ThriftColumnFamilyDataTypeTest.testCassandraStorageDataType(ThriftColumnFamilyDataTypeTest.java:150)
{noformat}

After a lengthy, tricky, painful bisect, I land back at CASSANDRA-5417.  This 
test fails 100% of the time, and given the error I don't see how it can 
possibly be a timing issue.  So I recreated this test using the cli and pig so 
I could run it manually, and I get this:

{noformat}
org.apache.cassandra.serializers.MarshalException: Invalid UTF-8 bytes deadbeef
at 
org.apache.cassandra.serializers.AbstractTextSerializer.deserialize(AbstractTextSerializer.java:43)
at 
org.apache.cassandra.serializers.AbstractTextSerializer.deserialize(AbstractTextSerializer.java:26)
at 
org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:142)
at 
org.apache.cassandra.hadoop.pig.AbstractCassandraStorage.columnToTuple(AbstractCassandraStorage.java:131)
at 
org.apache.cassandra.hadoop.pig.CassandraStorage.getNext(CassandraStorage.java:256)
at 
org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigRecordReader.nextKeyValue(PigRecordReader.java:194)
at 
org.apache.hadoop.mapred.MapTask$NewTrackingRecordReader.nextKeyValue(MapTask.java:532)
at 
org.apache.hadoop.mapreduce.MapContext.nextKeyValue(MapContext.java:67)
at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:143)
at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:764)
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:370)
at 
org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:212)
{noformat}

Which is interesting, since the deadbeef column is BytesType (verified in the 
cli), and the line in ACS that throws is also from CASSANDRA-5417.

I'm left to conclude that, if the problem is in pig, it's still 
CASSANDRA-5417's fault :)  I can attach the cli-ified script and very simple 
pig script to run against if needed.

> Pig test fails on 2.1 branch
> 
>
> Key: CASSANDRA-7241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7241
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Brandon Williams
> Fix For: 2.1 rc1
>
>
> run ant pig-test on cassandra-2.1 branch. There are many tests failed. I 
> trace it a little and find out Pig test fails starts from 
> https://github.com/apache/cassandra/commit/362cc05352ec67e707e0ac790732e96a15e63f6b
> commit.
> It looks like storage changes break Pig tests.



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

[jira] [Comment Edited] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[Pavel Yaskevich (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010285#comment-14010285
 ] 

Pavel Yaskevich edited comment on CASSANDRA-7245 at 5/27/14 9:18 PM:
-

That still leaves us with either 6861 or 5663, can you please generate with 
only 6861 reverted to rule out 5663?


was (Author: xedin):
It still leaves us with either 6861 or 5663, can you please generate with only 
6861 reverted to rule out 5663?

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[Pavel Yaskevich (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010285#comment-14010285
 ] 

Pavel Yaskevich commented on CASSANDRA-7245:


It still leaves us with either 6861 or 5663, can you please generate with only 
6861 reverted to rule out 5663?

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Commented] (CASSANDRA-4632) Increase default max_hint_window_in_ms to 3h

[Robert Coli (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010275#comment-14010275
 ] 

Robert Coli commented on CASSANDRA-4632:


For the record, I heartily endorse this change. 1 hour was too short for 
everything but the most trivial outage, 3 hours gives operators a chance. :)

> Increase default max_hint_window_in_ms to 3h
> 
>
> Key: CASSANDRA-4632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4632
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jonathan Ellis
>Assignee: Jonathan Ellis
>Priority: Trivial
> Fix For: 1.2.0 beta 1
>
> Attachments: 4632.txt
>
>
> It's clear at this point that CASSANDRA-2045 greatly reduced the impact of 
> storing hints for a dead node.  Let's increase the default window to make 
> full AES repair that much less necessary.



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

[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3

[Jason Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010271#comment-14010271
 ] 

Jason Brown commented on CASSANDRA-7245:


Reverted CASSANDRA-6861 as well as CASSANDRA-5663, and was unable to reproduce 
the keys out of order bug. I used a rather beefy, three node cluster and used 
this stress command:

{code}cassandra-stress write n=6 -schema replication\(factor\=2\) -key 
populate=1..6 -rate threads=42  -mode native prepared cql3 -port 
native=9043 thrift=9161  -col n=fixed\(21\) size=exp\(11..42\){code}

> Out-of-Order keys with stress + CQL3
> 
>
> Key: CASSANDRA-7245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Pavel Yaskevich
>Assignee: T Jake Luciani
> Fix For: 2.1 rc1
>
>
> We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 
> and found following problem almost in every SSTable generated (~200 GB of 
> data and 821 SSTables).
> We set up they keys to be 10 bytes in size (default) and population between 1 
> and 6.
> Once I ran 'sstablekeys' on the generated SSTable files I got following 
> exceptions:
> _There is a problem with sorting of normal looking keys:_
> 30303039443538353645
> 30303039443745364242
> java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, 
> *30303039443745364242*) > DecoratedKey(-1767746583617597213, 
> *30303039443437454333*)
> 0a30303033343933
> 3734441388343933
> java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, 
> *3734441388343933*) > DecoratedKey(-7565486415339257200, 
> *30303033344639443137*)
> 30303033354244363031
> 30303033354133423742
> java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, 
> *30303033354133423742*) > DecoratedKey(-7838239767410066684, 
> *30303033354145344534*)
> 30303034313442354137
> 3034313635363334
> java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, 
> *3034313635363334*) > DecoratedKey(-9106177395653818217, 
> *3030303431444238*)
> 30303035373044373435
> 30303035373044334631
> java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, 
> *30303035373044334631*) > DecoratedKey(-4296696226469000945, 
> *30303035373132364138*)
> _And completely different ones:_
> 30303041333745373543
> 7cd045c59a90d7587d8d
> java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, 
> *7cd045c59a90d7587d8d*) > DecoratedKey(-5146766422778260690, 
> *30303041333943303232*)
> 3030303332314144
> 30303033323346343932
> java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, 
> *30303033323346343932*) > DecoratedKey(5233296131921119414, 
> *53d83e0012287e03*)
> 30303034314531374431
> 3806734b256c27e41ec2
> java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, 
> *3806734b256c27e41ec2*) > DecoratedKey(-8072288379146044663, 
> *30303034314136413343*)
> _And sometimes there is no problem at all:_
> 30303033353144463637
> 002a31b3b31a1c2f
> 5d616dd38211ebb5d6ec
> 444236451388
> 1388138844463744
> 30303033353143394343
> It's worth to mention that we have got 22 timeout exceptions but number of 
> out-of-order keys is much larger than that.



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

[jira] [Commented] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Matt Kennedy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010231#comment-14010231
 ] 

Matt Kennedy commented on CASSANDRA-7306:
-

It should be noted that we can do some of this today by defining keyspaces that 
only have # of replicas > 0 in some data centers. But, gossip still needs to 
function over all the nodes.

Hub & Spoke functionality is useful in situations where the spokes are 
geographically dispersed, potentially in areas with less than ideal network 
connections. Local clients should be able to read/write locally relevant data 
on small scale clusters and make progress even when completely disconnected 
from the mothership without having to worry about replicating back a lot of 
data from unrelated DCs, or having to be networked to DCs halfway across the 
planet just to gossip between nodes that are otherwise unrelated.

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Tupshin Harper
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



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

[jira] [Commented] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Albert P Tobey (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010210#comment-14010210
 ] 

Albert P Tobey commented on CASSANDRA-7306:
---

Another angle: small edge clusters for low latency writes in many regions that 
push to a central warehouse for analytics. Think GSLB -> HTTP -> Cassandra all 
over the world with regional clusters replicated to us-west-2 where the data is 
crunched with Spark or Hadoop. This is basically the MySQL read-replica flipped 
on its head with 0-read write-replicas going into a read-heavy warehouse. The 
central cluster could be 100's of nodes while edge clusters are in the 5-10 
range.

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Tupshin Harper
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



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

[jira] [Commented] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Albert P Tobey (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010205#comment-14010205
 ] 

Albert P Tobey commented on CASSANDRA-7306:
---

One real use case is branch locations with local clusters that get replicated 
to a central datacenter for analytics. The central cluster has no authority to 
open ports or create VPNs in the plants, but it can open ports on the inbound 
side. In this situation, the easiest thing to do is to open the inbound ports 
to the central cluster and use TLS. The spokes obviously cannot communicate 
with each other, but they can push data to the hub. This kind of scenario is 
common in retail and manufacturing. Basically, it's useful anywhere there is 
hub-and-spoke topology where bidirectional communication is 
impossible/intermittent.

Another common problem is NAT traversal where VPN is not available. If there is 
no requirement for bi-directional replication, it gets a lot easier to deal 
with NAT since the spoke/leaf clusters can connect outbound through NAT into a 
centralized cluster. Generating all the firewall rules for such an setup is a 
lot of work and prone to error. If only one side needs to modify firewall 
policy, it's a lot easier to get right and troubleshoot.

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Tupshin Harper
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



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

[jira] [Commented] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Tupshin Harper (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010194#comment-14010194
 ] 

Tupshin Harper commented on CASSANDRA-7306:
---

#1 is definitely more ill-defined than it should be. The main thing I'd want to 
see is good overall cluster stability and behavior with 100s of spoke DCs that 
each could be offline up to 50% of the time (as a useful baseline). Until, and 
unless, that is formally tested, I don't have too much to add.

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Tupshin Harper
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



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

[jira] [Comment Edited] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Tupshin Harper (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010194#comment-14010194
 ] 

Tupshin Harper edited comment on CASSANDRA-7306 at 5/27/14 7:56 PM:


#1 is definitely more ill-defined than it should be. The main thing I'd want to 
see is good overall cluster stability and behavior with 100s of spoke DCs, 
where each DC could be offline up to 50% of the time (as a useful baseline). 
Until, and unless, that is formally tested, I don't have too much to add.


was (Author: tupshin):
#1 is definitely more ill-defined than it should be. The main thing I'd want to 
see is good overall cluster stability and behavior with 100s of spoke DCs that 
each could be offline up to 50% of the time (as a useful baseline). Until, and 
unless, that is formally tested, I don't have too much to add.

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Tupshin Harper
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



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

[jira] [Commented] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Brandon Williams (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010192#comment-14010192
 ] 

Brandon Williams commented on CASSANDRA-7306:
-

I get 2), but what do you have in mind exactly for 1)?

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Tupshin Harper
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



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

[jira] [Created] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Tupshin Harper (JIRA)]

Tupshin Harper created CASSANDRA-7306:
-

 Summary: Support "edge dcs" with more flexible gossip
 Key: CASSANDRA-7306
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Tupshin Harper


As Cassandra clusters get bigger and bigger, and their topology becomes more 
complex, there is more and more need for a notion of "hub" and "spoke" 
datacenters.

One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
is the assumption that all dcs need to talk to each other (and be connected all 
the time).

This ticket is a vague placeholder with the goals of achieving:
1) better behavioral support for occasionally disconnected datacenters
2) explicit support for custom dc to dc routing. A simple approach would be an 
optional per-dc annotation of which other DCs that DC could gossip with.



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

[jira] [Updated] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Tupshin Harper (JIRA)]

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

Tupshin Harper updated CASSANDRA-7306:
--

Labels: ponies  (was: )

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Tupshin Harper
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



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

[jira] [Resolved] (CASSANDRA-7141) Expand secondary_indexes_test for secondary indexes on sets and maps

[Shawn Kumar (JIRA)]

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

Shawn Kumar resolved CASSANDRA-7141.


Resolution: Fixed

> Expand secondary_indexes_test for secondary indexes on sets and maps
> 
>
> Key: CASSANDRA-7141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7141
> Project: Cassandra
>  Issue Type: Test
>Reporter: Shawn Kumar
>Assignee: Shawn Kumar
>Priority: Minor
>  Labels: qa-resolved
> Fix For: 2.1 rc1
>
>
> Secondary_indexes_test.py only checks functionality of secondary indexes on 
> lists as of now. This should be expanded to all collections, including maps 
> and sets.



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

[jira] [Updated] (CASSANDRA-7141) Expand secondary_indexes_test for secondary indexes on sets and maps

[Shawn Kumar (JIRA)]

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

Shawn Kumar updated CASSANDRA-7141:
---

Labels: qa-resolved  (was: )

> Expand secondary_indexes_test for secondary indexes on sets and maps
> 
>
> Key: CASSANDRA-7141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7141
> Project: Cassandra
>  Issue Type: Test
>Reporter: Shawn Kumar
>Assignee: Shawn Kumar
>Priority: Minor
>  Labels: qa-resolved
> Fix For: 2.1 rc1
>
>
> Secondary_indexes_test.py only checks functionality of secondary indexes on 
> lists as of now. This should be expanded to all collections, including maps 
> and sets.



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

[jira] [Commented] (CASSANDRA-7305) CQL3, Static columns not returning rows if values are not set

[Aleksey Yeschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009864#comment-14009864
 ] 

Aleksey Yeschenko commented on CASSANDRA-7305:
--

I think it's trickier than that. A similar query (one static, one regular 
column) SELECT b, c FROM statictest; - actually does return the correct result.

> CQL3, Static columns not returning rows if values are not set
> -
>
> Key: CASSANDRA-7305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7305
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Patrick Callaghan
>Assignee: Sylvain Lebresne
>
> Just a quick note on static columns, if you create some cql rows using 
> clustered columns and don't provide a value for a static column, then 
> selecting the row key with the (null) static column won't return any rows.
> create table statictest( a int, b text static, c text, PRIMARY KEY (a, c));
> insert into statictest (a, c) values (1, 'test');
> select a,b from statictest;
> (0 rows)



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

[jira] [Updated] (CASSANDRA-7305) CQL3, Static columns not returning rows if values are not set

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-7305:


Priority: Major  (was: Minor)

> CQL3, Static columns not returning rows if values are not set
> -
>
> Key: CASSANDRA-7305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7305
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Patrick Callaghan
>Assignee: Sylvain Lebresne
>
> Just a quick note on static columns, if you create some cql rows using 
> clustered columns and don't provide a value for a static column, then 
> selecting the row key with the (null) static column won't return any rows.
> create table statictest( a int, b text static, c text, PRIMARY KEY (a, c));
> insert into statictest (a, c) values (1, 'test');
> select a,b from statictest;
> (0 rows)



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

[jira] [Commented] (CASSANDRA-7305) CQL3, Static columns not returning rows if values are not set

[Sylvain Lebresne (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009853#comment-14009853
 ] 

Sylvain Lebresne commented on CASSANDRA-7305:
-

I agree that this is not a very consistent result. It stems from the fact that 
for static columns we said that when only the partition key and static columns 
where selected, the user probably didn't meant to query the full partition, and 
so we only query the static part of the partition, hence the result above.

In hindsight, I would agree that this is a mistake. We should make such query 
scan the whole partition the same way a selection of just the partition key 
still scan the full partition (and return as many results as there is rows).  
And we should extend DISTINCT so user can still query the static part 
efficiently.

This is going to potentially break current users of static columns however (but 
they are new enough that it's probably fair game to fix early mistake rather 
than carry them down indefinitely).


> CQL3, Static columns not returning rows if values are not set
> -
>
> Key: CASSANDRA-7305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7305
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Patrick Callaghan
>Assignee: Sylvain Lebresne
>Priority: Minor
>
> Just a quick note on static columns, if you create some cql rows using 
> clustered columns and don't provide a value for a static column, then 
> selecting the row key with the (null) static column won't return any rows.
> create table statictest( a int, b text static, c text, PRIMARY KEY (a, c));
> insert into statictest (a, c) values (1, 'test');
> select a,b from statictest;
> (0 rows)



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

[jira] [Reopened] (CASSANDRA-6875) CQL3: select multiple CQL rows in a single partition using IN

[Brandon Williams (JIRA)]

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

Brandon Williams reopened CASSANDRA-6875:
-


> CQL3: select multiple CQL rows in a single partition using IN
> -
>
> Key: CASSANDRA-6875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6875
> Project: Cassandra
>  Issue Type: Bug
>  Components: API
>Reporter: Nicolas Favre-Felix
>Assignee: Tyler Hobbs
>Priority: Minor
> Fix For: 2.0.9, 2.1 rc1
>
> Attachments: 6875-part2.txt
>
>
> In the spirit of CASSANDRA-4851 and to bring CQL to parity with Thrift, it is 
> important to support reading several distinct CQL rows from a given partition 
> using a distinct set of "coordinates" for these rows within the partition.
> CASSANDRA-4851 introduced a range scan over the multi-dimensional space of 
> clustering keys. We also need to support a "multi-get" of CQL rows, 
> potentially using the "IN" keyword to define a set of clustering keys to 
> fetch at once.
> (reusing the same example\:)
> Consider the following table:
> {code}
> CREATE TABLE test (
>   k int,
>   c1 int,
>   c2 int,
>   PRIMARY KEY (k, c1, c2)
> );
> {code}
> with the following data:
> {code}
>  k | c1 | c2
> ---++
>  0 |  0 |  0
>  0 |  0 |  1
>  0 |  1 |  0
>  0 |  1 |  1
> {code}
> We can fetch a single row or a range of rows, but not a set of them:
> {code}
> > SELECT * FROM test WHERE k = 0 AND (c1, c2) IN ((0, 0), (1,1)) ;
> Bad Request: line 1:54 missing EOF at ','
> {code}
> Supporting this syntax would return:
> {code}
>  k | c1 | c2
> ---++
>  0 |  0 |  0
>  0 |  1 |  1
> {code}
> Being able to fetch these two CQL rows in a single read is important to 
> maintain partition-level isolation.



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

[jira] [Updated] (CASSANDRA-6875) CQL3: select multiple CQL rows in a single partition using IN

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-6875:
---

Attachment: 6875-part2.txt

Good analysis, [~wtmitchell3].  We shouldn't need to adjust the bound for the 
comparator at all for IN queries (and the iterator was obviously being used 
incorrectly anyway).  6875-part2.txt fixes that and adds some unit test 
coverage for IN queries on reversed comparators and IN queries with more items 
than the number of components in the comparator..

> CQL3: select multiple CQL rows in a single partition using IN
> -
>
> Key: CASSANDRA-6875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6875
> Project: Cassandra
>  Issue Type: Bug
>  Components: API
>Reporter: Nicolas Favre-Felix
>Assignee: Tyler Hobbs
>Priority: Minor
> Fix For: 2.0.9, 2.1 rc1
>
> Attachments: 6875-part2.txt
>
>
> In the spirit of CASSANDRA-4851 and to bring CQL to parity with Thrift, it is 
> important to support reading several distinct CQL rows from a given partition 
> using a distinct set of "coordinates" for these rows within the partition.
> CASSANDRA-4851 introduced a range scan over the multi-dimensional space of 
> clustering keys. We also need to support a "multi-get" of CQL rows, 
> potentially using the "IN" keyword to define a set of clustering keys to 
> fetch at once.
> (reusing the same example\:)
> Consider the following table:
> {code}
> CREATE TABLE test (
>   k int,
>   c1 int,
>   c2 int,
>   PRIMARY KEY (k, c1, c2)
> );
> {code}
> with the following data:
> {code}
>  k | c1 | c2
> ---++
>  0 |  0 |  0
>  0 |  0 |  1
>  0 |  1 |  0
>  0 |  1 |  1
> {code}
> We can fetch a single row or a range of rows, but not a set of them:
> {code}
> > SELECT * FROM test WHERE k = 0 AND (c1, c2) IN ((0, 0), (1,1)) ;
> Bad Request: line 1:54 missing EOF at ','
> {code}
> Supporting this syntax would return:
> {code}
>  k | c1 | c2
> ---++
>  0 |  0 |  0
>  0 |  1 |  1
> {code}
> Being able to fetch these two CQL rows in a single read is important to 
> maintain partition-level isolation.



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

[jira] [Commented] (CASSANDRA-7279) MultiSliceTest.test_with_overlap* unit tests failing in trunk

[T Jake Luciani (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009814#comment-14009814
 ] 

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

Looks like some tests in org.apache.cassandra.cql3.MultiColumnRelationTest 
started failing due to assertion check

> MultiSliceTest.test_with_overlap* unit tests failing in trunk
> -
>
> Key: CASSANDRA-7279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7279
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tests
>Reporter: Michael Shuler
>Assignee: T Jake Luciani
>Priority: Minor
> Fix For: 2.1 rc1, 3.0
>
> Attachments: 7279-trunk.txt, 7279-trunkv2.txt, 7279-trunkv3.txt, 
> 7279-trunkv4.txt, 7279_alternative.txt
>
>
> Example:
> https://cassci.datastax.com/job/trunk_utest/623/testReport/org.apache.cassandra.thrift/MultiSliceTest/



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

[jira] [Commented] (CASSANDRA-7279) MultiSliceTest.test_with_overlap* unit tests failing in trunk

[Sylvain Lebresne (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009802#comment-14009802
 ] 

Sylvain Lebresne commented on CASSANDRA-7279:
-

bq. The CQL3CasConditions didn't look (at-a-glance-)trivial to me that it would 
definitely produce safe slices.

It's creating the slices by using the {{slice()}} method on composites coming 
from a map sorted by the comparator. But I'm happy with adding the assertion 
there (I suppose Jake can just chime that in his backport).

> MultiSliceTest.test_with_overlap* unit tests failing in trunk
> -
>
> Key: CASSANDRA-7279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7279
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tests
>Reporter: Michael Shuler
>Assignee: T Jake Luciani
>Priority: Minor
> Fix For: 2.1 rc1, 3.0
>
> Attachments: 7279-trunk.txt, 7279-trunkv2.txt, 7279-trunkv3.txt, 
> 7279-trunkv4.txt, 7279_alternative.txt
>
>
> Example:
> https://cassci.datastax.com/job/trunk_utest/623/testReport/org.apache.cassandra.thrift/MultiSliceTest/



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

[jira] [Updated] (CASSANDRA-7027) Back port MultiSliceRequest to 2.1

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-7027:
--

Fix Version/s: 2.1 rc1

> Back port MultiSliceRequest to 2.1
> --
>
> Key: CASSANDRA-7027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7027
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
> Fix For: 2.1 rc1
>
> Attachments: tests.txt
>
>




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

[jira] [Assigned] (CASSANDRA-7265) DataOutputTest unit test failure on Windows

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie reassigned CASSANDRA-7265:
--

Assignee: Joshua McKenzie

> DataOutputTest unit test failure on Windows
> ---
>
> Key: CASSANDRA-7265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7265
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Joshua McKenzie
>Assignee: Joshua McKenzie
>Priority: Minor
> Fix For: 3.0
>
>
> [junit] Testsuite: org.apache.cassandra.io.util.DataOutputTest
> [junit] Tests run: 8, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 
> 1.525 sec
> [junit]
> [junit] - Standard Output ---
> [junit] WARN  15:58:13 JNA link failure, one or more native method will 
> be unavailable.
> [junit] WARN  15:58:13 JNA link failure, one or more native method will 
> be unavailable.
> [junit] -  ---
> [junit] Testcase: 
> testSequentialWriter(org.apache.cassandra.io.util.DataOutputTest):FAILED
> [junit]
> [junit] junit.framework.AssertionFailedError:
> [junit] at 
> org.apache.cassandra.io.util.DataOutputTest.testSequentialWriter(DataOutputTest.java:142)
> [junit]
> [junit]
> [junit] Testcase: 
> testRandomAccessFile(org.apache.cassandra.io.util.DataOutputTest):FAILED
> [junit]
> [junit] junit.framework.AssertionFailedError:
> [junit] at 
> org.apache.cassandra.io.util.DataOutputTest.testRandomAccessFile(DataOutputTest.java:127)
> [junit]
> [junit]
> [junit] Testcase: 
> testFileOutputStream(org.apache.cassandra.io.util.DataOutputTest):FAILED
> [junit]
> [junit] junit.framework.AssertionFailedError:
> [junit] at 
> org.apache.cassandra.io.util.DataOutputTest.testFileOutputStream(DataOutputTest.java:108)
> [junit]
> [junit]
> [junit] Test org.apache.cassandra.io.util.DataOutputTest FAILED



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

[jira] [Updated] (CASSANDRA-7265) DataOutputTest unit test failure on Windows

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-7265:
---

Assignee: (was: Joshua McKenzie)

> DataOutputTest unit test failure on Windows
> ---
>
> Key: CASSANDRA-7265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7265
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Joshua McKenzie
>Priority: Minor
> Fix For: 3.0
>
>
> [junit] Testsuite: org.apache.cassandra.io.util.DataOutputTest
> [junit] Tests run: 8, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 
> 1.525 sec
> [junit]
> [junit] - Standard Output ---
> [junit] WARN  15:58:13 JNA link failure, one or more native method will 
> be unavailable.
> [junit] WARN  15:58:13 JNA link failure, one or more native method will 
> be unavailable.
> [junit] -  ---
> [junit] Testcase: 
> testSequentialWriter(org.apache.cassandra.io.util.DataOutputTest):FAILED
> [junit]
> [junit] junit.framework.AssertionFailedError:
> [junit] at 
> org.apache.cassandra.io.util.DataOutputTest.testSequentialWriter(DataOutputTest.java:142)
> [junit]
> [junit]
> [junit] Testcase: 
> testRandomAccessFile(org.apache.cassandra.io.util.DataOutputTest):FAILED
> [junit]
> [junit] junit.framework.AssertionFailedError:
> [junit] at 
> org.apache.cassandra.io.util.DataOutputTest.testRandomAccessFile(DataOutputTest.java:127)
> [junit]
> [junit]
> [junit] Testcase: 
> testFileOutputStream(org.apache.cassandra.io.util.DataOutputTest):FAILED
> [junit]
> [junit] junit.framework.AssertionFailedError:
> [junit] at 
> org.apache.cassandra.io.util.DataOutputTest.testFileOutputStream(DataOutputTest.java:108)
> [junit]
> [junit]
> [junit] Test org.apache.cassandra.io.util.DataOutputTest FAILED



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

[jira] [Commented] (CASSANDRA-7279) MultiSliceTest.test_with_overlap* unit tests failing in trunk

[T Jake Luciani (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009704#comment-14009704
 ] 

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

Ok +1 I'll backport this to 2.1 then commit. Thanks.

> MultiSliceTest.test_with_overlap* unit tests failing in trunk
> -
>
> Key: CASSANDRA-7279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7279
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tests
>Reporter: Michael Shuler
>Assignee: T Jake Luciani
>Priority: Minor
> Fix For: 2.1 rc1, 3.0
>
> Attachments: 7279-trunk.txt, 7279-trunkv2.txt, 7279-trunkv3.txt, 
> 7279-trunkv4.txt, 7279_alternative.txt
>
>
> Example:
> https://cassci.datastax.com/job/trunk_utest/623/testReport/org.apache.cassandra.thrift/MultiSliceTest/



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

[jira] [Assigned] (CASSANDRA-7305) CQL3, Static columns not returning rows if values are not set

[Brandon Williams (JIRA)]

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

Brandon Williams reassigned CASSANDRA-7305:
---

Assignee: Sylvain Lebresne

> CQL3, Static columns not returning rows if values are not set
> -
>
> Key: CASSANDRA-7305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7305
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Patrick Callaghan
>Assignee: Sylvain Lebresne
>Priority: Minor
>
> Just a quick note on static columns, if you create some cql rows using 
> clustered columns and don't provide a value for a static column, then 
> selecting the row key with the (null) static column won't return any rows.
> create table statictest( a int, b text static, c text, PRIMARY KEY (a, c));
> insert into statictest (a, c) values (1, 'test');
> select a,b from statictest;
> (0 rows)



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

[jira] [Commented] (CASSANDRA-7288) Exception during compaction

[Jonathan Ellis (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009671#comment-14009671
 ] 

Jonathan Ellis commented on CASSANDRA-7288:
---

+1 on the patch

> Exception during compaction
> ---
>
> Key: CASSANDRA-7288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7288
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Julien Anguenot
>Assignee: Marcus Eriksson
> Attachments: 
> 0001-make-sure-we-don-t-try-to-compact-already-compacting.patch, 
> compaction_exception.txt
>
>
> Sometimes Cassandra nodes (in a multi datacenter deployment) are throwing 
> errors during compaction. (see attached stack trace)
> Let me know what additional information I could provide.
> Thank you.



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

[jira] [Commented] (CASSANDRA-7288) Exception during compaction

[Julien Anguenot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009638#comment-14009638
 ] 

Julien Anguenot commented on CASSANDRA-7288:


Yes, this does not appear to be an issue. Though, we are monitoring Cassandra 
logs using syslog forward and 3rd party monitoring tool and would rather 
diminish alerts caused by this exception across the production nodes sooner 
than later.

Will this patch be included in 2.0.8? Do you want / need me to confirm this 
exception being gone with this patch to do so?

> Exception during compaction
> ---
>
> Key: CASSANDRA-7288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7288
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Julien Anguenot
>Assignee: Marcus Eriksson
> Attachments: 
> 0001-make-sure-we-don-t-try-to-compact-already-compacting.patch, 
> compaction_exception.txt
>
>
> Sometimes Cassandra nodes (in a multi datacenter deployment) are throwing 
> errors during compaction. (see attached stack trace)
> Let me know what additional information I could provide.
> Thank you.



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

[jira] [Commented] (CASSANDRA-7288) Exception during compaction

[Marcus Eriksson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009632#comment-14009632
 ] 

Marcus Eriksson commented on CASSANDRA-7288:


[~anguenot] It would probably be to check out the code from 
https://github.com/apache/cassandra , apply the patch and build locally

But, I don't think the exception is a big problem here, the hints will get 
compacted later anyway.

> Exception during compaction
> ---
>
> Key: CASSANDRA-7288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7288
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Julien Anguenot
>Assignee: Marcus Eriksson
> Attachments: 
> 0001-make-sure-we-don-t-try-to-compact-already-compacting.patch, 
> compaction_exception.txt
>
>
> Sometimes Cassandra nodes (in a multi datacenter deployment) are throwing 
> errors during compaction. (see attached stack trace)
> Let me know what additional information I could provide.
> Thank you.



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

[jira] [Commented] (CASSANDRA-7288) Exception during compaction

[Julien Anguenot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009626#comment-14009626
 ] 

Julien Anguenot commented on CASSANDRA-7288:


Thank you for the patch Marcus.

We have a development cluster with way less data than the production one where 
this compaction exception is never being thrown. What would be the best way / 
suggested way for us to test out this patch against one of the production node, 
where this exception is visible,  knowing we are running Cassandra 2.0.7 from 
deb packages on Ubuntu?

> Exception during compaction
> ---
>
> Key: CASSANDRA-7288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7288
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Julien Anguenot
>Assignee: Marcus Eriksson
> Attachments: 
> 0001-make-sure-we-don-t-try-to-compact-already-compacting.patch, 
> compaction_exception.txt
>
>
> Sometimes Cassandra nodes (in a multi datacenter deployment) are throwing 
> errors during compaction. (see attached stack trace)
> Let me know what additional information I could provide.
> Thank you.



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

[jira] [Commented] (CASSANDRA-4718) More-efficient ExecutorService for improved throughput

[Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009595#comment-14009595
 ] 

Benedict commented on CASSANDRA-4718:
-

I've uploaded an update to the branch which should permit spinning down the 
last thread much more simply (and correctly) than the previous patch did. I've 
also retested it to confirm the performance characteristics remain intact.

> More-efficient ExecutorService for improved throughput
> --
>
> Key: CASSANDRA-4718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4718
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Benedict
>Priority: Minor
>  Labels: performance
> Fix For: 2.1.0
>
> Attachments: 4718-v1.patch, E100M_summary_key_s.svg, 
> E10M_summary_key_s.svg, E600M_summary_key_s.svg, PerThreadQueue.java, 
> austin_diskbound_read.svg, aws.svg, aws_read.svg, 
> backpressure-stress.out.txt, baq vs trunk.png, 
> belliotsmith_branches-stress.out.txt, jason_read.svg, jason_read_latency.svg, 
> jason_run1.svg, jason_run2.svg, jason_run3.svg, jason_write.svg, op costs of 
> various queues.ods, stress op rate with various queues.ods, 
> stress_2014May15.txt, stress_2014May16.txt, v1-stress.out
>
>
> Currently all our execution stages dequeue tasks one at a time.  This can 
> result in contention between producers and consumers (although we do our best 
> to minimize this by using LinkedBlockingQueue).
> One approach to mitigating this would be to make consumer threads do more 
> work in "bulk" instead of just one task per dequeue.  (Producer threads tend 
> to be single-task oriented by nature, so I don't see an equivalent 
> opportunity there.)
> BlockingQueue has a drainTo(collection, int) method that would be perfect for 
> this.  However, no ExecutorService in the jdk supports using drainTo, nor 
> could I google one.
> What I would like to do here is create just such a beast and wire it into (at 
> least) the write and read stages.  (Other possible candidates for such an 
> optimization, such as the CommitLog and OutboundTCPConnection, are not 
> ExecutorService-based and will need to be one-offs.)
> AbstractExecutorService may be useful.  The implementations of 
> ICommitLogExecutorService may also be useful. (Despite the name these are not 
> actual ExecutorServices, although they share the most important properties of 
> one.)



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

[jira] [Created] (CASSANDRA-7305) CQL3, Static columns not returning rows if values are not set

[Patrick Callaghan (JIRA)]

Patrick Callaghan created CASSANDRA-7305:


 Summary: CQL3, Static columns not returning rows if values are not 
set
 Key: CASSANDRA-7305
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7305
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Patrick Callaghan


Just a quick note on static columns, if you create some cql rows using 
clustered columns and don't provide a value for a static column, then selecting 
the row key with the (null) static column won't return any rows.

create table statictest( a int, b text static, c text, PRIMARY KEY (a, c));
insert into statictest (a, c) values (1, 'test');
select a,b from statictest;

(0 rows)





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

[jira] [Updated] (CASSANDRA-7305) CQL3, Static columns not returning rows if values are not set

[Patrick Callaghan (JIRA)]

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

Patrick Callaghan updated CASSANDRA-7305:
-

Priority: Minor  (was: Major)

> CQL3, Static columns not returning rows if values are not set
> -
>
> Key: CASSANDRA-7305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7305
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Patrick Callaghan
>Priority: Minor
>
> Just a quick note on static columns, if you create some cql rows using 
> clustered columns and don't provide a value for a static column, then 
> selecting the row key with the (null) static column won't return any rows.
> create table statictest( a int, b text static, c text, PRIMARY KEY (a, c));
> insert into statictest (a, c) values (1, 'test');
> select a,b from statictest;
> (0 rows)



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

buildbot success in ASF Buildbot on cassandra-2.0

[buildbot]

The Buildbot has detected a restored build on builder cassandra-2.0 while 
building cassandra.
Full details are available at:
 http://ci.apache.org/builders/cassandra-2.0/builds/29

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: portunus_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch cassandra-2.0] 
9376fddccf202ec0506f2a94eb0a4f6bdf4a2852
Blamelist: Marcus Eriksson 

Build succeeded!

sincerely,
 -The Buildbot

[jira] [Updated] (CASSANDRA-7288) Exception during compaction

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-7288:
---

Attachment: 0001-make-sure-we-don-t-try-to-compact-already-compacting.patch

We add all sstables to a user defined compaction without checking if the 
sstables are actually compacting.

This means that if a compaction finishes after we add the descriptor to the 
user defined compaction, but before those sstables are marked compacting, we 
can end up compacting a file that is gone from the tracker and cause this assert

> Exception during compaction
> ---
>
> Key: CASSANDRA-7288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7288
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Julien Anguenot
>Assignee: Marcus Eriksson
> Attachments: 
> 0001-make-sure-we-don-t-try-to-compact-already-compacting.patch, 
> compaction_exception.txt
>
>
> Sometimes Cassandra nodes (in a multi datacenter deployment) are throwing 
> errors during compaction. (see attached stack trace)
> Let me know what additional information I could provide.
> Thank you.



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

[1/2] git commit: Add option to do more aggressive tombstone compaction.

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 8602fe8ce -> 86b6ec529


Add option to do more aggressive tombstone compaction.

Patch by pauloricardomg; reviewed by marcuse for CASSANDRA-6563


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

Branch: refs/heads/cassandra-2.1
Commit: 367c741931c2a20eb2213650313dc238e8b0f3aa
Parents: 9376fdd
Author: Marcus Eriksson 
Authored: Tue May 27 10:20:29 2014 +0200
Committer: Marcus Eriksson 
Committed: Tue May 27 10:39:17 2014 +0200

--
 CHANGES.txt |   1 +
 doc/cql3/CQL.textile|  21 ++--
 pylib/cqlshlib/cql3handling.py  |   2 +-
 .../compaction/AbstractCompactionStrategy.java  |  21 
 .../db/compaction/CompactionsTest.java  | 104 ---
 5 files changed, 123 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/367c7419/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 42a1148..6a16cae 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -3,6 +3,7 @@
  * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
  * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
  * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
+ * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
 
 2.0.8
  * Always reallocate buffers in HSHA (CASSANDRA-6285)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/367c7419/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 3c64bc6..393dc0d 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -335,16 +335,17 @@ h4(#compactionOptions). @compaction@ options
 
 The @compaction@ property must at least define the @'class'@ sub-option, that 
defines the compaction strategy class to use. The default supported class are 
@'SizeTieredCompactionStrategy'@ and @'LeveledCompactionStrategy'@. Custom 
strategy can be provided by specifying the full class name as a "string 
constant":#constants. The rest of the sub-options depends on the chosen class. 
The sub-options supported by the default classes are:
 
-|_. option|_. supported compaction strategy |_. 
default |_. description |
-| @enabled@   | _all_   | true 
 | A boolean denoting whether compaction should be enabled or not.|
-| @tombstone_threshold@   | _all_   | 0.2  
 | A ratio such that if a sstable has more than this ratio of gcable tombstones 
over all contained columns, the sstable will be compacted (with no other 
sstables) for the purpose of purging those tombstones. |
-| @tombstone_compaction_interval@ | _all_   | 1 day
 | The minimum time to wait after an sstable creation time before considering 
it for "tombstone compaction", where "tombstone compaction" is the compaction 
triggered if the sstable has more gcable tombstones than @tombstone_threshold@. 
|
-| @min_sstable_size@  | SizeTieredCompactionStrategy| 50MB 
 | The size tiered strategy groups SSTables to compact in buckets. A bucket 
groups SSTables that differs from less than 50% in size.  However, for small 
sizes, this would result in a bucketing that is too fine grained. 
@min_sstable_size@ defines a size threshold (in bytes) below which all SSTables 
belong to one unique bucket|
-| @min_threshold@ | SizeTieredCompactionStrategy| 4
 | Minimum number of SSTables needed to start a minor compaction.|
-| @max_threshold@ | SizeTieredCompactionStrategy| 32   
 | Maximum number of SSTables processed by one minor compaction.|
-| @bucket_low@| SizeTieredCompactionStrategy| 0.5  
 | Size tiered consider sstables to be within the same bucket if their size is 
within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the 
default groups sstable whose sizes diverges by at most 50%)|
-| @bucket_high@   | SizeTieredCompactionStrategy| 1.5  
 | Size tiered consider sstables to be within the same bucket if their size is 
within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the 
default groups sstable whose sizes diverges by at most 50%).|
-| @sstable_size_in_mb@| LeveledCompactionStrategy   | 5MB  
 | The target size (in MB) for sstables in the leveled strategy. 

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

[marcuse]

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/1b62f3d3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1b62f3d3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1b62f3d3

Branch: refs/heads/trunk
Commit: 1b62f3d39b219e7678b849c22a9980fa6a8805a7
Parents: 8ffb9cc 86b6ec5
Author: Marcus Eriksson 
Authored: Tue May 27 10:45:47 2014 +0200
Committer: Marcus Eriksson 
Committed: Tue May 27 10:49:25 2014 +0200

--
 CHANGES.txt |   1 +
 doc/cql3/CQL.textile|  21 ++--
 pylib/cqlshlib/cql3handling.py  |   2 +-
 .../compaction/AbstractCompactionStrategy.java  |  21 
 .../db/compaction/CompactionsTest.java  | 104 ---
 5 files changed, 125 insertions(+), 24 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b62f3d3/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
--
diff --cc test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
index 6671457,8a24771..a720375
--- a/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
+++ b/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
@@@ -18,19 -18,9 +18,20 @@@
  */
  package org.apache.cassandra.db.compaction;
  
 -import java.io.*;
 +import static org.junit.Assert.assertEquals;
 +import static org.junit.Assert.assertFalse;
 +import static org.junit.Assert.assertTrue;
 +import static org.junit.Assert.assertNotNull;
 +
 +import java.io.File;
  import java.nio.ByteBuffer;
 -import java.util.*;
 +import java.util.ArrayList;
 +import java.util.Collection;
 +import java.util.Collections;
++import java.util.Iterator;
 +import java.util.Map;
 +import java.util.Set;
 +import java.util.UUID;
  import java.util.concurrent.ExecutionException;
  import java.util.concurrent.TimeUnit;
  
@@@ -169,10 -158,80 +177,80 @@@ public class CompactionsTest extends Sc
  SSTableScanner scanner = 
sstable.getScanner(DataRange.forKeyRange(keyRange));
  OnDiskAtomIterator iter = scanner.next();
  assertEquals(key, iter.getKey());
 -assert iter.next() instanceof RangeTombstone;
 -assert !iter.hasNext();
 +assertTrue(iter.next() instanceof RangeTombstone);
 +assertFalse(iter.hasNext());
  }
  
+ @Test
+ public void testUncheckedTombstoneSizeTieredCompaction() throws Exception
+ {
+ Keyspace keyspace = Keyspace.open(KEYSPACE1);
+ ColumnFamilyStore store = keyspace.getColumnFamilyStore(STANDARD1);
+ store.clearUnsafe();
+ store.metadata.gcGraceSeconds(1);
+ 
store.metadata.compactionStrategyOptions.put("tombstone_compaction_interval", 
"1");
+ 
store.metadata.compactionStrategyOptions.put("unchecked_tombstone_compaction", 
"false");
+ store.reload();
+ 
store.setCompactionStrategyClass(SizeTieredCompactionStrategy.class.getName());
+ 
+ // disable compaction while flushing
+ store.disableAutoCompaction();
+ 
+ //Populate sstable1 with with keys [0..9]
+ populate(KEYSPACE1, STANDARD1, 0, 9, 3); //ttl=3s
+ store.forceBlockingFlush();
+ 
+ //Populate sstable2 with with keys [10..19] (keys do not overlap with 
SSTable1)
+ long timestamp2 = populate(KEYSPACE1, STANDARD1, 10, 19, 3); //ttl=3s
+ store.forceBlockingFlush();
+ 
+ assertEquals(2, store.getSSTables().size());
+ 
+ Iterator it = store.getSSTables().iterator();
+ long originalSize1 = it.next().uncompressedLength();
+ long originalSize2 = it.next().uncompressedLength();
+ 
+ // wait enough to force single compaction
+ TimeUnit.SECONDS.sleep(5);
+ 
+ // enable compaction, submit background and wait for it to complete
+ store.enableAutoCompaction();
+ 
FBUtilities.waitOnFutures(CompactionManager.instance.submitBackground(store));
+ while (CompactionManager.instance.getPendingTasks() > 0 || 
CompactionManager.instance.getActiveCompactions() > 0)
+ TimeUnit.SECONDS.sleep(1);
+ 
+ // even though both sstables were candidate for tombstone compaction
+ // it was not executed because they have an overlapping token range
+ assertEquals(2, store.getSSTables().size());
+ it = store.getSSTables().iterator();
+ long newSize1 = it.next().uncompressedLength();
+ long newSize2 = it.next().uncompressedLength();
+ assertEquals("candidate sstable should not be tomb

[1/3] git commit: Add option to do more aggressive tombstone compaction.

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 8ffb9cc3f -> 1b62f3d39


Add option to do more aggressive tombstone compaction.

Patch by pauloricardomg; reviewed by marcuse for CASSANDRA-6563


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

Branch: refs/heads/trunk
Commit: 367c741931c2a20eb2213650313dc238e8b0f3aa
Parents: 9376fdd
Author: Marcus Eriksson 
Authored: Tue May 27 10:20:29 2014 +0200
Committer: Marcus Eriksson 
Committed: Tue May 27 10:39:17 2014 +0200

--
 CHANGES.txt |   1 +
 doc/cql3/CQL.textile|  21 ++--
 pylib/cqlshlib/cql3handling.py  |   2 +-
 .../compaction/AbstractCompactionStrategy.java  |  21 
 .../db/compaction/CompactionsTest.java  | 104 ---
 5 files changed, 123 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/367c7419/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 42a1148..6a16cae 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -3,6 +3,7 @@
  * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
  * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
  * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
+ * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
 
 2.0.8
  * Always reallocate buffers in HSHA (CASSANDRA-6285)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/367c7419/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 3c64bc6..393dc0d 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -335,16 +335,17 @@ h4(#compactionOptions). @compaction@ options
 
 The @compaction@ property must at least define the @'class'@ sub-option, that 
defines the compaction strategy class to use. The default supported class are 
@'SizeTieredCompactionStrategy'@ and @'LeveledCompactionStrategy'@. Custom 
strategy can be provided by specifying the full class name as a "string 
constant":#constants. The rest of the sub-options depends on the chosen class. 
The sub-options supported by the default classes are:
 
-|_. option|_. supported compaction strategy |_. 
default |_. description |
-| @enabled@   | _all_   | true 
 | A boolean denoting whether compaction should be enabled or not.|
-| @tombstone_threshold@   | _all_   | 0.2  
 | A ratio such that if a sstable has more than this ratio of gcable tombstones 
over all contained columns, the sstable will be compacted (with no other 
sstables) for the purpose of purging those tombstones. |
-| @tombstone_compaction_interval@ | _all_   | 1 day
 | The minimum time to wait after an sstable creation time before considering 
it for "tombstone compaction", where "tombstone compaction" is the compaction 
triggered if the sstable has more gcable tombstones than @tombstone_threshold@. 
|
-| @min_sstable_size@  | SizeTieredCompactionStrategy| 50MB 
 | The size tiered strategy groups SSTables to compact in buckets. A bucket 
groups SSTables that differs from less than 50% in size.  However, for small 
sizes, this would result in a bucketing that is too fine grained. 
@min_sstable_size@ defines a size threshold (in bytes) below which all SSTables 
belong to one unique bucket|
-| @min_threshold@ | SizeTieredCompactionStrategy| 4
 | Minimum number of SSTables needed to start a minor compaction.|
-| @max_threshold@ | SizeTieredCompactionStrategy| 32   
 | Maximum number of SSTables processed by one minor compaction.|
-| @bucket_low@| SizeTieredCompactionStrategy| 0.5  
 | Size tiered consider sstables to be within the same bucket if their size is 
within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the 
default groups sstable whose sizes diverges by at most 50%)|
-| @bucket_high@   | SizeTieredCompactionStrategy| 1.5  
 | Size tiered consider sstables to be within the same bucket if their size is 
within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the 
default groups sstable whose sizes diverges by at most 50%).|
-| @sstable_size_in_mb@| LeveledCompactionStrategy   | 5MB  
 | The target size (in MB) for sstables in the leveled strategy. Note that 
while

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

[marcuse]

Merge branch 'cassandra-2.0' into cassandra-2.1

Conflicts:
CHANGES.txt
test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java


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

Branch: refs/heads/trunk
Commit: 86b6ec529979ceeeb2ae15704b82f18beb1258b2
Parents: 8602fe8 367c741
Author: Marcus Eriksson 
Authored: Tue May 27 10:43:50 2014 +0200
Committer: Marcus Eriksson 
Committed: Tue May 27 10:43:50 2014 +0200

--
 CHANGES.txt |   1 +
 doc/cql3/CQL.textile|  21 ++--
 pylib/cqlshlib/cql3handling.py  |   2 +-
 .../compaction/AbstractCompactionStrategy.java  |  21 
 .../db/compaction/CompactionsTest.java  | 103 ---
 5 files changed, 124 insertions(+), 24 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/86b6ec52/CHANGES.txt
--
diff --cc CHANGES.txt
index fcc1e73,6a16cae..6240e1e
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,32 -1,11 +1,33 @@@
 -2.0.9
 - * Add missing iso8601 patterns for date strings (6973)
 - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
 - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
 +2.1.0-rc1
 + * Add tab-completion to debian nodetool packaging (CASSANDRA-6421)
 + * Change concurrent_compactors defaults (CASSANDRA-7139)
 + * Add PowerShell Windows launch scripts (CASSANDRA-7001)
 + * Make commitlog archive+restore more robust (CASSANDRA-6974)
 + * Fix marking commitlogsegments clean (CASSANDRA-6959)
 + * Add snapshot "manifest" describing files included (CASSANDRA-6326)
 + * Parallel streaming for sstableloader (CASSANDRA-3668)
 + * Fix bugs in supercolumns handling (CASSANDRA-7138)
 + * Fix ClassClassException on composite dense tables (CASSANDRA-7112)
 + * Cleanup and optimize collation and slice iterators (CASSANDRA-7107)
 + * Upgrade NBHM lib (CASSANDRA-7128)
 + * Optimize netty server (CASSANDRA-6861)
 + * Fix repair hang when given CF does not exist (CASSANDRA-7189)
 + * Allow c* to be shutdown in an embedded mode (CASSANDRA-5635)
 + * Add server side batching to native transport (CASSANDRA-5663)
 + * Make batchlog replay asynchronous (CASSANDRA-6134)
 + * remove unused classes (CASSANDRA-7197)
 + * Limit user types to the keyspace they are defined in (CASSANDRA-6643)
 + * Add validate method to CollectionType (CASSANDRA-7208)
 + * New serialization format for UDT values (CASSANDRA-7209, CASSANDRA-7261)
 + * Fix nodetool netstats (CASSANDRA-7270)
 + * Fix potential ClassCastException in HintedHandoffManager (CASSANDRA-7284)
 + * Use prepared statements internally (CASSANDRA-6975)
 + * Fix broken paging state with prepared statement (CASSANDRA-7120)
 + * Fix IllegalArgumentException in CqlStorage (CASSANDRA-7287)
 + * Allow nulls/non-existant fields in UDT (CASSANDRA-7206)
 +Merged from 2.0:
   * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
+  * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
 -
 -2.0.8
   * Always reallocate buffers in HSHA (CASSANDRA-6285)
   * (Hadoop) support authentication in CqlRecordReader (CASSANDRA-7221)
   * (Hadoop) Close java driver Cluster in CQLRR.close (CASSANDRA-7228)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/86b6ec52/doc/cql3/CQL.textile
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/86b6ec52/pylib/cqlshlib/cql3handling.py
--
diff --cc pylib/cqlshlib/cql3handling.py
index e4364a0,b2557fe..2710941
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@@ -74,11 -79,9 +74,11 @@@ class Cql3ParsingRuleSet(CqlParsingRule
  # (CQL3 option name, schema_columnfamilies column name (or None if 
same),
  #  list of known map keys)
  ('compaction', 'compaction_strategy_options',
- ('class', 'max_threshold', 'tombstone_compaction_interval', 
'tombstone_threshold', 'enabled')),
+ ('class', 'max_threshold', 'tombstone_compaction_interval', 
'tombstone_threshold', 'enabled', 'unchecked_tombstone_compaction')),
  ('compression', 'compression_parameters',
  ('sstable_compression', 'chunk_length_kb', 'crc_check_chance')),
 +('caching', None,
 +('rows_per_partition', 'keys')),
  )
  
  obsolete_cf_options = ()

http://git-wip-us.apache.org/repos/asf/cassandra/blob/86b6ec52/src/java/org/apache/cassandra/db/compaction/A

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

[marcuse]

Merge branch 'cassandra-2.0' into cassandra-2.1

Conflicts:
CHANGES.txt
test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java


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

Branch: refs/heads/cassandra-2.1
Commit: 86b6ec529979ceeeb2ae15704b82f18beb1258b2
Parents: 8602fe8 367c741
Author: Marcus Eriksson 
Authored: Tue May 27 10:43:50 2014 +0200
Committer: Marcus Eriksson 
Committed: Tue May 27 10:43:50 2014 +0200

--
 CHANGES.txt |   1 +
 doc/cql3/CQL.textile|  21 ++--
 pylib/cqlshlib/cql3handling.py  |   2 +-
 .../compaction/AbstractCompactionStrategy.java  |  21 
 .../db/compaction/CompactionsTest.java  | 103 ---
 5 files changed, 124 insertions(+), 24 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/86b6ec52/CHANGES.txt
--
diff --cc CHANGES.txt
index fcc1e73,6a16cae..6240e1e
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,32 -1,11 +1,33 @@@
 -2.0.9
 - * Add missing iso8601 patterns for date strings (6973)
 - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
 - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
 +2.1.0-rc1
 + * Add tab-completion to debian nodetool packaging (CASSANDRA-6421)
 + * Change concurrent_compactors defaults (CASSANDRA-7139)
 + * Add PowerShell Windows launch scripts (CASSANDRA-7001)
 + * Make commitlog archive+restore more robust (CASSANDRA-6974)
 + * Fix marking commitlogsegments clean (CASSANDRA-6959)
 + * Add snapshot "manifest" describing files included (CASSANDRA-6326)
 + * Parallel streaming for sstableloader (CASSANDRA-3668)
 + * Fix bugs in supercolumns handling (CASSANDRA-7138)
 + * Fix ClassClassException on composite dense tables (CASSANDRA-7112)
 + * Cleanup and optimize collation and slice iterators (CASSANDRA-7107)
 + * Upgrade NBHM lib (CASSANDRA-7128)
 + * Optimize netty server (CASSANDRA-6861)
 + * Fix repair hang when given CF does not exist (CASSANDRA-7189)
 + * Allow c* to be shutdown in an embedded mode (CASSANDRA-5635)
 + * Add server side batching to native transport (CASSANDRA-5663)
 + * Make batchlog replay asynchronous (CASSANDRA-6134)
 + * remove unused classes (CASSANDRA-7197)
 + * Limit user types to the keyspace they are defined in (CASSANDRA-6643)
 + * Add validate method to CollectionType (CASSANDRA-7208)
 + * New serialization format for UDT values (CASSANDRA-7209, CASSANDRA-7261)
 + * Fix nodetool netstats (CASSANDRA-7270)
 + * Fix potential ClassCastException in HintedHandoffManager (CASSANDRA-7284)
 + * Use prepared statements internally (CASSANDRA-6975)
 + * Fix broken paging state with prepared statement (CASSANDRA-7120)
 + * Fix IllegalArgumentException in CqlStorage (CASSANDRA-7287)
 + * Allow nulls/non-existant fields in UDT (CASSANDRA-7206)
 +Merged from 2.0:
   * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
+  * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
 -
 -2.0.8
   * Always reallocate buffers in HSHA (CASSANDRA-6285)
   * (Hadoop) support authentication in CqlRecordReader (CASSANDRA-7221)
   * (Hadoop) Close java driver Cluster in CQLRR.close (CASSANDRA-7228)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/86b6ec52/doc/cql3/CQL.textile
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/86b6ec52/pylib/cqlshlib/cql3handling.py
--
diff --cc pylib/cqlshlib/cql3handling.py
index e4364a0,b2557fe..2710941
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@@ -74,11 -79,9 +74,11 @@@ class Cql3ParsingRuleSet(CqlParsingRule
  # (CQL3 option name, schema_columnfamilies column name (or None if 
same),
  #  list of known map keys)
  ('compaction', 'compaction_strategy_options',
- ('class', 'max_threshold', 'tombstone_compaction_interval', 
'tombstone_threshold', 'enabled')),
+ ('class', 'max_threshold', 'tombstone_compaction_interval', 
'tombstone_threshold', 'enabled', 'unchecked_tombstone_compaction')),
  ('compression', 'compression_parameters',
  ('sstable_compression', 'chunk_length_kb', 'crc_check_chance')),
 +('caching', None,
 +('rows_per_partition', 'keys')),
  )
  
  obsolete_cf_options = ()

http://git-wip-us.apache.org/repos/asf/cassandra/blob/86b6ec52/src/java/org/apache/cassandra/db/comp

git commit: Add option to do more aggressive tombstone compaction.

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.0 9376fddcc -> 367c74193


Add option to do more aggressive tombstone compaction.

Patch by pauloricardomg; reviewed by marcuse for CASSANDRA-6563


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

Branch: refs/heads/cassandra-2.0
Commit: 367c741931c2a20eb2213650313dc238e8b0f3aa
Parents: 9376fdd
Author: Marcus Eriksson 
Authored: Tue May 27 10:20:29 2014 +0200
Committer: Marcus Eriksson 
Committed: Tue May 27 10:39:17 2014 +0200

--
 CHANGES.txt |   1 +
 doc/cql3/CQL.textile|  21 ++--
 pylib/cqlshlib/cql3handling.py  |   2 +-
 .../compaction/AbstractCompactionStrategy.java  |  21 
 .../db/compaction/CompactionsTest.java  | 104 ---
 5 files changed, 123 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/367c7419/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 42a1148..6a16cae 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -3,6 +3,7 @@
  * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
  * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
  * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
+ * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
 
 2.0.8
  * Always reallocate buffers in HSHA (CASSANDRA-6285)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/367c7419/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 3c64bc6..393dc0d 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -335,16 +335,17 @@ h4(#compactionOptions). @compaction@ options
 
 The @compaction@ property must at least define the @'class'@ sub-option, that 
defines the compaction strategy class to use. The default supported class are 
@'SizeTieredCompactionStrategy'@ and @'LeveledCompactionStrategy'@. Custom 
strategy can be provided by specifying the full class name as a "string 
constant":#constants. The rest of the sub-options depends on the chosen class. 
The sub-options supported by the default classes are:
 
-|_. option|_. supported compaction strategy |_. 
default |_. description |
-| @enabled@   | _all_   | true 
 | A boolean denoting whether compaction should be enabled or not.|
-| @tombstone_threshold@   | _all_   | 0.2  
 | A ratio such that if a sstable has more than this ratio of gcable tombstones 
over all contained columns, the sstable will be compacted (with no other 
sstables) for the purpose of purging those tombstones. |
-| @tombstone_compaction_interval@ | _all_   | 1 day
 | The minimum time to wait after an sstable creation time before considering 
it for "tombstone compaction", where "tombstone compaction" is the compaction 
triggered if the sstable has more gcable tombstones than @tombstone_threshold@. 
|
-| @min_sstable_size@  | SizeTieredCompactionStrategy| 50MB 
 | The size tiered strategy groups SSTables to compact in buckets. A bucket 
groups SSTables that differs from less than 50% in size.  However, for small 
sizes, this would result in a bucketing that is too fine grained. 
@min_sstable_size@ defines a size threshold (in bytes) below which all SSTables 
belong to one unique bucket|
-| @min_threshold@ | SizeTieredCompactionStrategy| 4
 | Minimum number of SSTables needed to start a minor compaction.|
-| @max_threshold@ | SizeTieredCompactionStrategy| 32   
 | Maximum number of SSTables processed by one minor compaction.|
-| @bucket_low@| SizeTieredCompactionStrategy| 0.5  
 | Size tiered consider sstables to be within the same bucket if their size is 
within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the 
default groups sstable whose sizes diverges by at most 50%)|
-| @bucket_high@   | SizeTieredCompactionStrategy| 1.5  
 | Size tiered consider sstables to be within the same bucket if their size is 
within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the 
default groups sstable whose sizes diverges by at most 50%).|
-| @sstable_size_in_mb@| LeveledCompactionStrategy   | 5MB  
 | The target size (in MB) for sstables in the leveled strategy. 

[jira] [Updated] (CASSANDRA-7290) Compaction strategy is not reloaded when compaction strategy options is updated

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-7290:
---

Reproduced In: 2.0.7, 1.2.16  (was: 1.2.16, 2.0.7)
 Assignee: Paulo Motta

> Compaction strategy is not reloaded when compaction strategy options is 
> updated
> ---
>
> Key: CASSANDRA-7290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7290
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Paulo Motta
>Assignee: Paulo Motta
> Fix For: 2.0.9
>
>
> The AbstractCompactionStrategy constructor receives an options map on its 
> constructor:
> {code:java}
> protected AbstractCompactionStrategy(ColumnFamilyStore cfs, Map String> options)
> {
> assert cfs != null;
> this.cfs = cfs;
> this.options = options;
> ...
> {code}
> This map is currently the same reference as 
> CFMetadata.compactionStrategyOptions, so ColumnFamilyStore.reload() does not 
> reload the compaction strategy when a compaction strategy option changes:
> {code:java}
> private void maybeReloadCompactionStrategy()
> {
> // Check if there is a need for reloading
> if 
> (metadata.compactionStrategyClass.equals(compactionStrategy.getClass()) 
> && 
> metadata.compactionStrategyOptions.equals(compactionStrategy.options)) 
> //metadata.compactionStrategyOptions == compactionStrategy.options, so 
> compaction is never reloaded
> return;
> {code}
> I spotted this in my test, when I tried changing the value of 
> "unchecked_tombstone_compaction" from false to true and calling 
> ColumnFamilyStore.reload() was not reloading the compaction strategy. I don't 
> know if ColumnFamilyStore.reload() is only called during tests, or also 
> whenever the schema changes. 
> In order to fix the bug, I made AbstractCompactionStrategy.options an 
> ImmutableMap, so if CFMetadata.compactionStrategyOptions is updated, 
> ColumnFamilyStore.maybeReloadCompactionStrategy will actually reload the 
> compaction strategy:
> {code:java}
> protected AbstractCompactionStrategy(ColumnFamilyStore cfs, Map String> options)
> {
> assert cfs != null;
> this.cfs = cfs;
> this.options = ImmutableMap.copyOf(options);
> ...
> {code}



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