date:20130514

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

Rick Branson commented on CASSANDRA-5565:
-

After thinking about this a bit, I think the right approach is to have the rest
of the cluster reject nodes that try to connect with an existing broadcast
address and a different hostID / token set. I tried to think through the
various scenarios, and I can't think of any legitimate reason you'd need to do
this. An ERROR-level log should be spit out on the nodes that rejected the
connection with something like: /{IP} attempted to join with different host ID
/ token(s). If this is intentional, please use 'nodetool removenode {hostID}'
to safely remove the previous host ID from the cluster.

I can work up a patch for this if others think this is a solid approach.

Maybe we also need a -force option on nodetool removenode to provide access to
the previous behavior?

Peer entry drops from system table silently when bootstrapping a node with an
existing IP.
--

Key: CASSANDRA-5565
URL: https://issues.apache.org/jira/browse/CASSANDRA-5565
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Reporter: Rick Branson

It looks like CASSANDRA-5167 introduced a bit of a regression. I needed to
rebuild the data on a malfunctioning node by rebootstrapping it. I did this
by cleaning the host and restarting Cassandra. My plan was to remove the old
hostID once it had successfully bootstrapped.
No errors were encountered, but the old host ID of the node before the wipe
was completely dropped from the peers table because they had the same IP
address, and therefore the data ranges were moved around. This resulted in a
large number of CL.ONE reads coming back empty.
There might be a better approach to this rebootstrap process, but it seems
like it's dangerous to just drop the peer from the table, especially without
any kind of log message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-5565) Peer entry drops from system table silently when bootstrapping a node with an existing IP.

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

Rick Branson edited comment on CASSANDRA-5565 at 5/14/13 4:11 PM:
--

After thinking about this a bit, I think the right approach is to have the rest
of the cluster reject nodes that try to connect with an existing broadcast
address and a different hostID / token set. I tried to think through the
various scenarios, and I can't think of any legitimate reason you'd need to do
this. An ERROR-level log should be spit out on the nodes that rejected the
connection with something like: /IP attempted to join with different host ID
/ token(s). If this is intentional, please use 'nodetool removenode hostID'
to safely remove the previous host ID from the cluster.

I can work up a patch for this if others think this is a solid approach.

Maybe we also need a -force option on nodetool removenode to provide access to
the previous behavior?

was (Author: rbranson):
After thinking about this a bit, I think the right approach is to have the
rest of the cluster reject nodes that try to connect with an existing broadcast
address and a different hostID / token set. I tried to think through the
various scenarios, and I can't think of any legitimate reason you'd need to do
this. An ERROR-level log should be spit out on the nodes that rejected the
connection with something like: /{IP} attempted to join with different host ID
/ token(s). If this is intentional, please use 'nodetool removenode {hostID}'
to safely remove the previous host ID from the cluster.

I can work up a patch for this if others think this is a solid approach.

Maybe we also need a -force option on nodetool removenode to provide access to
the previous behavior?

Peer entry drops from system table silently when bootstrapping a node with an
existing IP.
--

Key: CASSANDRA-5565
URL: https://issues.apache.org/jira/browse/CASSANDRA-5565
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Reporter: Rick Branson

[1/3] git commit: make BytesToken.toString only return hex bytes patch by Juraj Sustek; reviewed by jbellis for CASSANDRA-5566

Updated Branches:
  refs/heads/cassandra-1.2 11b0cfbe7 - 3950de9e8
  refs/heads/trunk 4adb583c2 - 025477471


make BytesToken.toString only return hex bytes
patch by Juraj Sustek; reviewed by jbellis for CASSANDRA-5566


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

Branch: refs/heads/cassandra-1.2
Commit: 3950de9e830b8e5c21367ce98f7b34a5049dac00
Parents: 11b0cfb
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue May 14 13:33:57 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue May 14 13:33:57 2013 -0500

--
 CHANGES.txt   |1 +
 src/java/org/apache/cassandra/dht/BytesToken.java |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3950de9e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index df13e6a..6432775 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 1.2.5
+ * make BytesToken.toString only return hex bytes (CASSANDRA-5566)
  * Ensure that submitBackground enqueues at least one task (CASSANDRA-5554)
  * fix 2i updates with identical values and timestamps (CASSANDRA-5540)
  * fix compaction throttling bursty-ness (CASSANDRA-4316)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3950de9e/src/java/org/apache/cassandra/dht/BytesToken.java
--
diff --git a/src/java/org/apache/cassandra/dht/BytesToken.java 
b/src/java/org/apache/cassandra/dht/BytesToken.java
index a95eb98..f2f9eab 100644
--- a/src/java/org/apache/cassandra/dht/BytesToken.java
+++ b/src/java/org/apache/cassandra/dht/BytesToken.java
@@ -41,7 +41,7 @@ public class BytesToken extends Tokenbyte[]
 @Override
 public String toString()
 {
-return Token(bytes[ + Hex.bytesToHex(token) + ]);
+return Hex.bytesToHex(token);
 }
 
 public int compareTo(Tokenbyte[] o)

[2/3] git commit: make BytesToken.toString only return hex bytes patch by Juraj Sustek; reviewed by jbellis for CASSANDRA-5566

make BytesToken.toString only return hex bytes
patch by Juraj Sustek; reviewed by jbellis for CASSANDRA-5566


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

Branch: refs/heads/trunk
Commit: 3950de9e830b8e5c21367ce98f7b34a5049dac00
Parents: 11b0cfb
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue May 14 13:33:57 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue May 14 13:33:57 2013 -0500

--
 CHANGES.txt   |1 +
 src/java/org/apache/cassandra/dht/BytesToken.java |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3950de9e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index df13e6a..6432775 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 1.2.5
+ * make BytesToken.toString only return hex bytes (CASSANDRA-5566)
  * Ensure that submitBackground enqueues at least one task (CASSANDRA-5554)
  * fix 2i updates with identical values and timestamps (CASSANDRA-5540)
  * fix compaction throttling bursty-ness (CASSANDRA-4316)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3950de9e/src/java/org/apache/cassandra/dht/BytesToken.java
--
diff --git a/src/java/org/apache/cassandra/dht/BytesToken.java 
b/src/java/org/apache/cassandra/dht/BytesToken.java
index a95eb98..f2f9eab 100644
--- a/src/java/org/apache/cassandra/dht/BytesToken.java
+++ b/src/java/org/apache/cassandra/dht/BytesToken.java
@@ -41,7 +41,7 @@ public class BytesToken extends Tokenbyte[]
 @Override
 public String toString()
 {
-return Token(bytes[ + Hex.bytesToHex(token) + ]);
+return Hex.bytesToHex(token);
 }
 
 public int compareTo(Tokenbyte[] o)

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

Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: 02547747198c0d14f9a4102a920b914bcfd57a23
Parents: 4adb583 3950de9
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue May 14 13:34:04 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue May 14 13:34:04 2013 -0500

--
 CHANGES.txt   |1 +
 src/java/org/apache/cassandra/dht/BytesToken.java |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/02547747/CHANGES.txt
--
diff --cc CHANGES.txt
index c137922,6432775..019dc16
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,52 -1,5 +1,53 @@@
 +2.0
 + * JEMalloc support for off-heap allocation (CASSANDRA-3997)
 + * Single-pass compaction (CASSANDRA-4180)
 + * Removed token range bisection (CASSANDRA-5518)
 + * Removed compatibility with pre-1.2.5 sstables and network messages
 +   (CASSANDRA-5511)
 + * removed PBSPredictor (CASSANDRA-5455)
 + * CAS support (CASSANDRA-5062, 5441, 5443)
 + * Leveled compaction performs size-tiered compactions in L0 
 +   (CASSANDRA-5371, 5439)
 + * Add yaml network topology snitch for mixed ec2/other envs (CASSANDRA-5339)
 + * Log when a node is down longer than the hint window (CASSANDRA-4554)
 + * Optimize tombstone creation for ExpiringColumns (CASSANDRA-4917)
 + * Improve LeveledScanner work estimation (CASSANDRA-5250, 5407)
 + * Replace compaction lock with runWithCompactionsDisabled (CASSANDRA-3430)
 + * Change Message IDs to ints (CASSANDRA-5307)
 + * Move sstable level information into the Stats component, removing the
 +   need for a separate Manifest file (CASSANDRA-4872)
 + * avoid serializing to byte[] on commitlog append (CASSANDRA-5199)
 + * make index_interval configurable per columnfamily (CASSANDRA-3961)
 + * add default_time_to_live (CASSANDRA-3974)
 + * add memtable_flush_period_in_ms (CASSANDRA-4237)
 + * replace supercolumns internally by composites (CASSANDRA-3237, 5123)
 + * upgrade thrift to 0.9.0 (CASSANDRA-3719)
 + * drop unnecessary keyspace parameter from user-defined compaction API 
 +   (CASSANDRA-5139)
 + * more robust solution to incomplete compactions + counters (CASSANDRA-5151)
 + * Change order of directory searching for c*.in.sh (CASSANDRA-3983)
 + * Add tool to reset SSTable compaction level for LCS (CASSANDRA-5271)
 + * Allow custom configuration loader (CASSANDRA-5045)
 + * Remove memory emergency pressure valve logic (CASSANDRA-3534)
 + * Reduce request latency with eager retry (CASSANDRA-4705)
 + * cqlsh: Remove ASSUME command (CASSANDRA-5331)
 + * Rebuild BF when loading sstables if bloom_filter_fp_chance
 +   has changed since compaction (CASSANDRA-5015)
 + * remove row-level bloom filters (CASSANDRA-4885)
 + * Change Kernel Page Cache skipping into row preheating (disabled by default)
 +   (CASSANDRA-4937)
 + * Improve repair by deciding on a gcBefore before sending
 +   out TreeRequests (CASSANDRA-4932)
 + * Add an official way to disable compactions (CASSANDRA-5074)
 + * Reenable ALTER TABLE DROP with new semantics (CASSANDRA-3919)
 + * Add binary protocol versioning (CASSANDRA-5436)
 + * Swap THshaServer for TThreadedSelectorServer (CASSANDRA-5530)
 + * Add alias support to SELECT statement (CASSANDRA-5075)
 + * Don't create empty RowMutations in CommitLogReplayer (CASSANDRA-5541)
 +
 +
  1.2.5
+  * make BytesToken.toString only return hex bytes (CASSANDRA-5566)
   * Ensure that submitBackground enqueues at least one task (CASSANDRA-5554)
   * fix 2i updates with identical values and timestamps (CASSANDRA-5540)
   * fix compaction throttling bursty-ness (CASSANDRA-4316)

[jira] [Updated] (CASSANDRA-5566) java/org/apache/cassandra/dht/BytesToken.java returns invalid string token (with prefix Token(bytes[ + Hex.bytesToHex(token) + ]))


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

Jonathan Ellis updated CASSANDRA-5566:
--

 Reviewer: jbellis
Affects Version/s: (was: 1.2.4)
   1.2.0
Fix Version/s: 1.2.5
 Assignee: Juraj Sustek

Kind of bizarre that we're passing String representations of tokens around, but 
this is probably the easiest fix.  Committed.

 java/org/apache/cassandra/dht/BytesToken.java returns invalid string token 
 (with prefix   Token(bytes[ + Hex.bytesToHex(token) + ]))
 --

 Key: CASSANDRA-5566
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5566
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0
 Environment: debian x86_64 GNU/Linux, 
 eff3c455ac73ac482a6fcf5cec111abc  apache-cassandra-1.2.4-src.tar.gz
Reporter: Juraj Sustek
Assignee: Juraj Sustek
Priority: Minor
  Labels: newbie
 Fix For: 1.2.5


 BytesToken java class method toString returns invalid token. 
 Changing java/org/apache/cassandra/dht/BytesToken.java
 line 44 from:
 return Token(bytes[ + Hex.bytesToHex(token) + ]);
 to:
 return Hex.bytesToHex(token);
 shuffle works fine.
 when you run:
 ./cassandra-shuffle -h localhost create
 cassandra throws:
 Exception in thread main java.lang.NumberFormatException: Non-hex 
 characters in Token(bytes[d439e5e5ad484679a0c1f045fea7b2a3])
 at org.apache.cassandra.utils.Hex.hexToBytes(Hex.java:60)
 at 
 org.apache.cassandra.dht.AbstractByteOrderedPartitioner$1.fromString(AbstractByteOrderedPartitioner.java:168)
 at 
 org.apache.cassandra.tools.Shuffle.createShuffleBatchInsert(Shuffle.java:580)
 at org.apache.cassandra.tools.Shuffle.shuffle(Shuffle.java:358)
 at org.apache.cassandra.tools.Shuffle.main(Shuffle.java:678)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5565) Peer entry drops from system table silently when bootstrapping a node with an existing IP.

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

Brandon Williams commented on CASSANDRA-5565:
-

I'm not sure what the problem is here. If you wiped the node and restarted it,
it would get new tokens and you'd have to removenode the old one, which would
still be around. After that, everything should be normal (though I'll note
CASSANDRA-5337 will ultimately be a superior way of doing this.) Also worth
noting you can, painfully, specify all the tokens to replace_token in a csv
list.

Peer entry drops from system table silently when bootstrapping a node with an
existing IP.
--

Key: CASSANDRA-5565
URL: https://issues.apache.org/jira/browse/CASSANDRA-5565
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Reporter: Rick Branson

[jira] [Updated] (CASSANDRA-5566) java/org/apache/cassandra/dht/BytesToken.java returns invalid string token (with prefix Token(bytes[ + Hex.bytesToHex(token) + ]))


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

Brandon Williams updated CASSANDRA-5566:


Labels:   (was: newbie)

 java/org/apache/cassandra/dht/BytesToken.java returns invalid string token 
 (with prefix   Token(bytes[ + Hex.bytesToHex(token) + ]))
 --

 Key: CASSANDRA-5566
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5566
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0
 Environment: debian x86_64 GNU/Linux, 
 eff3c455ac73ac482a6fcf5cec111abc  apache-cassandra-1.2.4-src.tar.gz
Reporter: Juraj Sustek
Assignee: Juraj Sustek
Priority: Minor
 Fix For: 1.2.5


 BytesToken java class method toString returns invalid token. 
 Changing java/org/apache/cassandra/dht/BytesToken.java
 line 44 from:
 return Token(bytes[ + Hex.bytesToHex(token) + ]);
 to:
 return Hex.bytesToHex(token);
 shuffle works fine.
 when you run:
 ./cassandra-shuffle -h localhost create
 cassandra throws:
 Exception in thread main java.lang.NumberFormatException: Non-hex 
 characters in Token(bytes[d439e5e5ad484679a0c1f045fea7b2a3])
 at org.apache.cassandra.utils.Hex.hexToBytes(Hex.java:60)
 at 
 org.apache.cassandra.dht.AbstractByteOrderedPartitioner$1.fromString(AbstractByteOrderedPartitioner.java:168)
 at 
 org.apache.cassandra.tools.Shuffle.createShuffleBatchInsert(Shuffle.java:580)
 at org.apache.cassandra.tools.Shuffle.shuffle(Shuffle.java:358)
 at org.apache.cassandra.tools.Shuffle.main(Shuffle.java:678)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-5566) java/org/apache/cassandra/dht/BytesToken.java returns invalid string token (with prefix Token(bytes[ + Hex.bytesToHex(token) + ]))


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

Brandon Williams resolved CASSANDRA-5566.
-

Resolution: Fixed

 java/org/apache/cassandra/dht/BytesToken.java returns invalid string token 
 (with prefix   Token(bytes[ + Hex.bytesToHex(token) + ]))
 --

 Key: CASSANDRA-5566
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5566
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0
 Environment: debian x86_64 GNU/Linux, 
 eff3c455ac73ac482a6fcf5cec111abc  apache-cassandra-1.2.4-src.tar.gz
Reporter: Juraj Sustek
Assignee: Juraj Sustek
Priority: Minor
 Fix For: 1.2.5


 BytesToken java class method toString returns invalid token. 
 Changing java/org/apache/cassandra/dht/BytesToken.java
 line 44 from:
 return Token(bytes[ + Hex.bytesToHex(token) + ]);
 to:
 return Hex.bytesToHex(token);
 shuffle works fine.
 when you run:
 ./cassandra-shuffle -h localhost create
 cassandra throws:
 Exception in thread main java.lang.NumberFormatException: Non-hex 
 characters in Token(bytes[d439e5e5ad484679a0c1f045fea7b2a3])
 at org.apache.cassandra.utils.Hex.hexToBytes(Hex.java:60)
 at 
 org.apache.cassandra.dht.AbstractByteOrderedPartitioner$1.fromString(AbstractByteOrderedPartitioner.java:168)
 at 
 org.apache.cassandra.tools.Shuffle.createShuffleBatchInsert(Shuffle.java:580)
 at org.apache.cassandra.tools.Shuffle.shuffle(Shuffle.java:358)
 at org.apache.cassandra.tools.Shuffle.main(Shuffle.java:678)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[2/3] git commit: sstablescrub respects MAX_HEAP_SIZE Patch by Mina Naguib, reviewed by brandonwilliams for CASSANDRA-5562

2013-05-14 Thread brandonwilliams

sstablescrub respects MAX_HEAP_SIZE
Patch by Mina Naguib, reviewed by brandonwilliams for CASSANDRA-5562


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

Branch: refs/heads/trunk
Commit: 14139455a5f88b1d64a0686f1d02162293f0d8c9
Parents: 3950de9
Author: Brandon Williams brandonwilli...@apache.org
Authored: Tue May 14 14:08:12 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Tue May 14 14:08:12 2013 -0500

--
 CHANGES.txt  |1 +
 bin/sstablescrub |6 +-
 2 files changed, 6 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/14139455/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6432775..498f447 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -32,6 +32,7 @@ Merged from 1.1
  * Fix trying to load deleted row into row cache on startup (CASSANDRA-4463)
  * fsync leveled manifest to avoid corruption (CASSANDRA-5535)
  * Fix Bound intersection computation (CASSANDRA-5551)
+ * sstablescrub now respects max memory size in cassandra.in.sh 
(CASSANDRA-5562)
 
 
 1.2.4

http://git-wip-us.apache.org/repos/asf/cassandra/blob/14139455/bin/sstablescrub
--
diff --git a/bin/sstablescrub b/bin/sstablescrub
index 437bee0..fdf23a5 100755
--- a/bin/sstablescrub
+++ b/bin/sstablescrub
@@ -43,7 +43,11 @@ if [ -z $CLASSPATH ]; then
 exit 1
 fi
 
-$JAVA -ea -cp $CLASSPATH -Xmx256M \
+if [ x$MAX_HEAP_SIZE = x ]; then
+MAX_HEAP_SIZE=256M
+fi
+
+$JAVA -ea -cp $CLASSPATH -Xmx$MAX_HEAP_SIZE \
 -Dlog4j.configuration=log4j-tools.properties \
 org.apache.cassandra.tools.StandaloneScrubber $@

[1/3] git commit: sstablescrub respects MAX_HEAP_SIZE Patch by Mina Naguib, reviewed by brandonwilliams for CASSANDRA-5562

2013-05-14 Thread brandonwilliams

Updated Branches:
  refs/heads/cassandra-1.2 3950de9e8 - 14139455a
  refs/heads/trunk 025477471 - 42dc743d6


sstablescrub respects MAX_HEAP_SIZE
Patch by Mina Naguib, reviewed by brandonwilliams for CASSANDRA-5562


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

Branch: refs/heads/cassandra-1.2
Commit: 14139455a5f88b1d64a0686f1d02162293f0d8c9
Parents: 3950de9
Author: Brandon Williams brandonwilli...@apache.org
Authored: Tue May 14 14:08:12 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Tue May 14 14:08:12 2013 -0500

--
 CHANGES.txt  |1 +
 bin/sstablescrub |6 +-
 2 files changed, 6 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/14139455/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6432775..498f447 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -32,6 +32,7 @@ Merged from 1.1
  * Fix trying to load deleted row into row cache on startup (CASSANDRA-4463)
  * fsync leveled manifest to avoid corruption (CASSANDRA-5535)
  * Fix Bound intersection computation (CASSANDRA-5551)
+ * sstablescrub now respects max memory size in cassandra.in.sh 
(CASSANDRA-5562)
 
 
 1.2.4

http://git-wip-us.apache.org/repos/asf/cassandra/blob/14139455/bin/sstablescrub
--
diff --git a/bin/sstablescrub b/bin/sstablescrub
index 437bee0..fdf23a5 100755
--- a/bin/sstablescrub
+++ b/bin/sstablescrub
@@ -43,7 +43,11 @@ if [ -z $CLASSPATH ]; then
 exit 1
 fi
 
-$JAVA -ea -cp $CLASSPATH -Xmx256M \
+if [ x$MAX_HEAP_SIZE = x ]; then
+MAX_HEAP_SIZE=256M
+fi
+
+$JAVA -ea -cp $CLASSPATH -Xmx$MAX_HEAP_SIZE \
 -Dlog4j.configuration=log4j-tools.properties \
 org.apache.cassandra.tools.StandaloneScrubber $@

[jira] [Resolved] (CASSANDRA-5562) sstablescrub should respect MAX_HEAP_SIZE


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

Brandon Williams resolved CASSANDRA-5562.
-

   Resolution: Fixed
Fix Version/s: 1.2.5
 Reviewer: brandon.williams
 Assignee: (was: Brandon Williams)

Sounds reasonable, committed.

 sstablescrub should respect MAX_HEAP_SIZE
 -

 Key: CASSANDRA-5562
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5562
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Mina Naguib
Priority: Minor
  Labels: MAX_HEAP_SIZE, heap, oom, sstablescrub, xmx
 Fix For: 1.2.5

 Attachments: CASSANDRA-5562-sstablescrub_max_heap_size.patch


 sstablescrub has Xmx hardcoded to 256MB.  This is not enough in my 
 installation and causes an OOM.
 Since it's meant to be run offline, the memory usually allocated to the 
 daemon can be safely given to the tool.
 Attached is a patch that makes it respect $MAX_HEAP_SIZE (with fallback to 
 256MB if not defined)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-5562) sstablescrub should respect MAX_HEAP_SIZE


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

Brandon Williams reassigned CASSANDRA-5562:
---

Assignee: Mina Naguib

 sstablescrub should respect MAX_HEAP_SIZE
 -

 Key: CASSANDRA-5562
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5562
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Mina Naguib
Assignee: Mina Naguib
Priority: Minor
  Labels: MAX_HEAP_SIZE, heap, oom, sstablescrub, xmx
 Fix For: 1.2.5

 Attachments: CASSANDRA-5562-sstablescrub_max_heap_size.patch


 sstablescrub has Xmx hardcoded to 256MB.  This is not enough in my 
 installation and causes an OOM.
 Since it's meant to be run offline, the memory usually allocated to the 
 daemon can be safely given to the tool.
 Attached is a patch that makes it respect $MAX_HEAP_SIZE (with fallback to 
 256MB if not defined)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-5567) DESCRIBE TABLES is empty after case insensitive use

2013-05-14 Thread Mike Bulman (JIRA)

Mike Bulman created CASSANDRA-5567:
--

 Summary: DESCRIBE TABLES is empty after case insensitive use
 Key: CASSANDRA-5567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5567
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Mike Bulman


Using trunk @ 02547747198c0d14f9a4102a920b914bcfd57a23

{noformat}
trunk*:~/src/cassandra$ bin/cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 3.0.2 | Cassandra 2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 
19.37.0]
Use HELP for help.
cqlsh create keyspace Test with replication={'class':'SimpleStrategy', 
'replication_factor':1};
cqlsh use Test;
cqlsh:Test CREATE TABLE users (   user_name varchar PRIMARY KEY,   password 
varchar,   gender varchar,   session_token varchar,   state varchar,   
birth_year bigint );
cqlsh:Test describe tables;

empty

cqlsh:Test use test;
cqlsh:test describe tables;

users

cqlsh:test
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-5567) DESCRIBE TABLES is empty after case insensitive use


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

Jonathan Ellis reassigned CASSANDRA-5567:
-

Assignee: Aleksey Yeschenko

 DESCRIBE TABLES is empty after case insensitive use
 ---

 Key: CASSANDRA-5567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5567
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Mike Bulman
Assignee: Aleksey Yeschenko

 Using trunk @ 02547747198c0d14f9a4102a920b914bcfd57a23
 {noformat}
 trunk*:~/src/cassandra$ bin/cqlsh -3
 Connected to Test Cluster at localhost:9160.
 [cqlsh 3.0.2 | Cassandra 2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 
 19.37.0]
 Use HELP for help.
 cqlsh create keyspace Test with replication={'class':'SimpleStrategy', 
 'replication_factor':1};
 cqlsh use Test;
 cqlsh:Test CREATE TABLE users (   user_name varchar PRIMARY KEY,   password 
 varchar,   gender varchar,   session_token varchar,   state varchar,   
 birth_year bigint );
 cqlsh:Test describe tables;
 empty
 cqlsh:Test use test;
 cqlsh:test describe tables;
 users
 cqlsh:test
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5567) DESCRIBE TABLES is empty after case insensitive use


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

Jonathan Ellis updated CASSANDRA-5567:
--

 Priority: Trivial  (was: Major)
Fix Version/s: 1.2.5

 DESCRIBE TABLES is empty after case insensitive use
 ---

 Key: CASSANDRA-5567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5567
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Mike Bulman
Assignee: Aleksey Yeschenko
Priority: Trivial
 Fix For: 1.2.5


 Using trunk @ 02547747198c0d14f9a4102a920b914bcfd57a23
 {noformat}
 trunk*:~/src/cassandra$ bin/cqlsh -3
 Connected to Test Cluster at localhost:9160.
 [cqlsh 3.0.2 | Cassandra 2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 
 19.37.0]
 Use HELP for help.
 cqlsh create keyspace Test with replication={'class':'SimpleStrategy', 
 'replication_factor':1};
 cqlsh use Test;
 cqlsh:Test CREATE TABLE users (   user_name varchar PRIMARY KEY,   password 
 varchar,   gender varchar,   session_token varchar,   state varchar,   
 birth_year bigint );
 cqlsh:Test describe tables;
 empty
 cqlsh:Test use test;
 cqlsh:test describe tables;
 users
 cqlsh:test
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: switch Paxos debug logging to Tracing

Updated Branches:
  refs/heads/trunk 42dc743d6 - 2dcbf0673


switch Paxos debug logging to Tracing


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

Branch: refs/heads/trunk
Commit: 2dcbf0673e01e0977bf18814dc99d93b63b2a2be
Parents: 42dc743
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue May 14 15:30:38 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue May 14 15:30:56 2013 -0500

--
 .../org/apache/cassandra/service/StorageProxy.java |   18 +++---
 .../apache/cassandra/service/paxos/PaxosState.java |9 ---
 2 files changed, 14 insertions(+), 13 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2dcbf067/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java 
b/src/java/org/apache/cassandra/service/StorageProxy.java
index 696569c..f170039 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -213,7 +213,7 @@ public class StorageProxy implements StorageProxyMBean
 continue;
 
 // read the current value and compare with expected
-logger.debug(Reading existing values for CAS precondition);
+Tracing.trace(Reading existing values for CAS precondition);
 ReadCommand readCommand = expected == null
 ? new SliceFromReadCommand(table, key, 
cfName, new SliceQueryFilter(ByteBufferUtil.EMPTY_BYTE_BUFFER, 
ByteBufferUtil.EMPTY_BYTE_BUFFER, false, 1))
 : new SliceByNamesReadCommand(table, key, 
cfName, new 
NamesQueryFilter(ImmutableSortedSet.copyOf(expected.getColumnNames(;
@@ -221,22 +221,22 @@ public class StorageProxy implements StorageProxyMBean
 ColumnFamily current = rows.get(0).cf;
 if (!casApplies(expected, current))
 {
-logger.debug(CAS precondition {} does not match current 
values {}, expected, current);
+Tracing.trace(CAS precondition {} does not match current 
values {}, expected, current);
 return false;
 }
 
 // finish the paxos round w/ the desired updates
 // TODO turn null updates into delete?
 Commit proposal = Commit.newProposal(key, ballot, updates);
-logger.debug(CAS precondition is met; proposing client-requested 
updates for {}, ballot);
+Tracing.trace(CAS precondition is met; proposing client-requested 
updates for {}, ballot);
 if (proposePaxos(proposal, liveEndpoints, requiredParticipants))
 {
 commitPaxos(proposal, liveEndpoints);
-logger.debug(Paxos CAS successful);
+Tracing.trace(CAS successful);
 return true;
 }
 
-logger.debug(Paxos proposal not accepted (pre-empted by a higher 
ballot));
+Tracing.trace(Paxos proposal not accepted (pre-empted by a higher 
ballot));
 
Uninterruptibles.sleepUninterruptibly(FBUtilities.threadLocalRandom().nextInt(100),
 TimeUnit.MILLISECONDS);
 // continue to retry
 }
@@ -301,12 +301,12 @@ public class StorageProxy implements StorageProxyMBean
 UUID ballot = UUIDGen.getTimeUUID();
 
 // prepare
-logger.debug(Preparing {}, ballot);
+Tracing.trace(Preparing {}, ballot);
 Commit toPrepare = Commit.newPrepare(key, metadata, ballot);
 PrepareCallback summary = preparePaxos(toPrepare, liveEndpoints, 
requiredParticipants);
 if (!summary.promised)
 {
-logger.debug(Some replicas have already promised a higher ballot 
than ours; aborting);
+Tracing.trace(Some replicas have already promised a higher ballot 
than ours; aborting);
 // sleep a random amount to give the other proposer a chance to 
finish
 
Uninterruptibles.sleepUninterruptibly(FBUtilities.threadLocalRandom().nextInt(100),
 TimeUnit.MILLISECONDS);
 return null;
@@ -319,7 +319,7 @@ public class StorageProxy implements StorageProxyMBean
 // needs to be completed, so do it.
 if (!inProgress.update.isEmpty()  inProgress.isAfter(mostRecent))
 {
-logger.debug(Finishing incomplete paxos round {}, inProgress);
+Tracing.trace(Finishing incomplete paxos round {}, inProgress);
 if (proposePaxos(inProgress, liveEndpoints, requiredParticipants))

[jira] [Commented] (CASSANDRA-5443) Add CAS CQL support


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

Jonathan Ellis commented on CASSANDRA-5443:
---

The tracing I see suggests that this is actually executing StorageProxy.mutate 
instead of SP.cas:

{noformat}
cqlsh:foo update bar set j=1 where i=1 if not exists;

 activity  | timestamp| source| source_elapsed
---+--+---+
execute_cql3_query | 15:24:50,122 | 127.0.0.1 |  0
 Parsing statement | 15:24:50,122 | 127.0.0.1 | 68
Peparing statement | 15:24:50,123 | 127.0.0.1 |482
 Determining replicas for mutation | 15:24:50,123 | 127.0.0.1 |762
Acquiring switchLock read lock | 15:24:50,124 | 127.0.0.1 |   1790
Appending to commitlog | 15:24:50,124 | 127.0.0.1 |   1815
Adding to bar memtable | 15:24:50,124 | 127.0.0.1 |   1871
  Request complete | 15:24:50,124 | 127.0.0.1 |   2246
{noformat}

it's not just the IF EXISTS syntax:

{noformat}
cqlsh:foo update bar set j=2 where i=1 if j=1;

 activity  | timestamp| source| source_elapsed
---+--+---+
execute_cql3_query | 15:25:32,657 | 127.0.0.1 |  0
 Parsing statement | 15:25:32,657 | 127.0.0.1 | 47
Peparing statement | 15:25:32,657 | 127.0.0.1 |306
 Determining replicas for mutation | 15:25:32,657 | 127.0.0.1 |457
Acquiring switchLock read lock | 15:25:32,658 | 127.0.0.1 |   1082
Appending to commitlog | 15:25:32,658 | 127.0.0.1 |   1106
Adding to bar memtable | 15:25:32,658 | 127.0.0.1 |   1163
  Request complete | 15:25:32,658 | 127.0.0.1 |   1440
{noformat}

 Add CAS CQL support
 ---

 Key: CASSANDRA-5443
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5443
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
 Fix For: 2.0

 Attachments: 
 0001-Refactor-Update-and-Delete-statement-to-extract-common.txt, 
 0002-Add-syntax-to-support-conditional-update-delete.txt, 
 0003-Handle-deleted-and-expiring-column-in-paxos-updates.txt, 
 0004-Support-tombstones-when-comparing-for-CAS.txt, 
 0005-add-UPDATE-.-IF-NOT-EXISTS-syntax.txt, 
 0006-Make-EXISTS-a-reserverd-keyword.txt




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-5443) Add CAS CQL support


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

Jonathan Ellis edited comment on CASSANDRA-5443 at 5/14/13 8:29 PM:


The tracing I see suggests that this is actually executing StorageProxy.mutate 
instead of SP.cas:

{noformat}
cqlsh:foo update bar set j=1 where i=1 if not exists;

 activity  | timestamp| source| source_elapsed
---+--+---+
execute_cql3_query | 15:24:50,122 | 127.0.0.1 |  0
 Parsing statement | 15:24:50,122 | 127.0.0.1 | 68
Peparing statement | 15:24:50,123 | 127.0.0.1 |482
 Determining replicas for mutation | 15:24:50,123 | 127.0.0.1 |762
Acquiring switchLock read lock | 15:24:50,124 | 127.0.0.1 |   1790
Appending to commitlog | 15:24:50,124 | 127.0.0.1 |   1815
Adding to bar memtable | 15:24:50,124 | 127.0.0.1 |   1871
  Request complete | 15:24:50,124 | 127.0.0.1 |   2246
{noformat}

it's not just the IF EXISTS syntax:

{noformat}
cqlsh:foo update bar set j=2 where i=1 if j=1;

 activity  | timestamp| source| source_elapsed
---+--+---+
execute_cql3_query | 15:25:32,657 | 127.0.0.1 |  0
 Parsing statement | 15:25:32,657 | 127.0.0.1 | 47
Peparing statement | 15:25:32,657 | 127.0.0.1 |306
 Determining replicas for mutation | 15:25:32,657 | 127.0.0.1 |457
Acquiring switchLock read lock | 15:25:32,658 | 127.0.0.1 |   1082
Appending to commitlog | 15:25:32,658 | 127.0.0.1 |   1106
Adding to bar memtable | 15:25:32,658 | 127.0.0.1 |   1163
  Request complete | 15:25:32,658 | 127.0.0.1 |   1440
{noformat}

(determining replicas for mutation is only logged by {{mutate}}.)

  was (Author: jbellis):
The tracing I see suggests that this is actually executing 
StorageProxy.mutate instead of SP.cas:

{noformat}
cqlsh:foo update bar set j=1 where i=1 if not exists;

 activity  | timestamp| source| source_elapsed
---+--+---+
execute_cql3_query | 15:24:50,122 | 127.0.0.1 |  0
 Parsing statement | 15:24:50,122 | 127.0.0.1 | 68
Peparing statement | 15:24:50,123 | 127.0.0.1 |482
 Determining replicas for mutation | 15:24:50,123 | 127.0.0.1 |762
Acquiring switchLock read lock | 15:24:50,124 | 127.0.0.1 |   1790
Appending to commitlog | 15:24:50,124 | 127.0.0.1 |   1815
Adding to bar memtable | 15:24:50,124 | 127.0.0.1 |   1871
  Request complete | 15:24:50,124 | 127.0.0.1 |   2246
{noformat}

it's not just the IF EXISTS syntax:

{noformat}
cqlsh:foo update bar set j=2 where i=1 if j=1;

 activity  | timestamp| source| source_elapsed
---+--+---+
execute_cql3_query | 15:25:32,657 | 127.0.0.1 |  0
 Parsing statement | 15:25:32,657 | 127.0.0.1 | 47
Peparing statement | 15:25:32,657 | 127.0.0.1 |306
 Determining replicas for mutation | 15:25:32,657 | 127.0.0.1 |457
Acquiring switchLock read lock | 15:25:32,658 | 127.0.0.1 |   1082
Appending to commitlog | 15:25:32,658 | 127.0.0.1 |   1106
Adding to bar memtable | 15:25:32,658 | 127.0.0.1 |   1163
  Request complete | 15:25:32,658 | 127.0.0.1 |   1440
{noformat}
  
 Add CAS CQL support
 ---

 Key: CASSANDRA-5443
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5443
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
 Fix For: 2.0

 Attachments: 
 0001-Refactor-Update-and-Delete-statement-to-extract-common.txt, 
 0002-Add-syntax-to-support-conditional-update-delete.txt, 
 0003-Handle-deleted-and-expiring-column-in-paxos-updates.txt, 
 0004-Support-tombstones-when-comparing-for-CAS.txt, 
 0005-add-UPDATE-.-IF-NOT-EXISTS-syntax.txt, 
 0006-Make-EXISTS-a-reserverd-keyword.txt




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please

[jira] [Reopened] (CASSANDRA-5443) Add CAS CQL support


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

Jonathan Ellis reopened CASSANDRA-5443:
---


 Add CAS CQL support
 ---

 Key: CASSANDRA-5443
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5443
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
 Fix For: 2.0

 Attachments: 
 0001-Refactor-Update-and-Delete-statement-to-extract-common.txt, 
 0002-Add-syntax-to-support-conditional-update-delete.txt, 
 0003-Handle-deleted-and-expiring-column-in-paxos-updates.txt, 
 0004-Support-tombstones-when-comparing-for-CAS.txt, 
 0005-add-UPDATE-.-IF-NOT-EXISTS-syntax.txt, 
 0006-Make-EXISTS-a-reserverd-keyword.txt




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5565) Peer entry drops from system table silently when bootstrapping a node with an existing IP.

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

Rick Branson commented on CASSANDRA-5565:
-

That's exactly what I expected to occur. As soon as the node I wiped joined,
the tokens from it's previous incarnation were completely dropped from the
ring, causing the ranges to shift. Perhaps I'm improperly blaming
CASSANDRA-5167, but that was the result.

Peer entry drops from system table silently when bootstrapping a node with an
existing IP.
--

Key: CASSANDRA-5565
URL: https://issues.apache.org/jira/browse/CASSANDRA-5565
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Reporter: Rick Branson

[jira] [Assigned] (CASSANDRA-5442) Add support for specifying CAS commit CL


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

Jonathan Ellis reassigned CASSANDRA-5442:
-

Assignee: Sylvain Lebresne

Pushed updates to StorageProxy and Thrift to 
https://github.com/jbellis/cassandra/commits/5442.  Doesn't actually build b/c 
of the CQL side.

 Add support for specifying CAS commit CL
 

 Key: CASSANDRA-5442
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5442
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
 Fix For: 2.0




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5565) Peer entry drops from system table silently when bootstrapping a node with an existing IP.

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

Brandon Williams commented on CASSANDRA-5565:
-

bq. As soon as the node I wiped joined, the tokens from it's previous
incarnation were completely dropped from the ring

I can't imagine how that is possible without a removenode/decom/assassinate,
but I'll investigate. Usually our problem is getting things out of gossip, not
having them disappear :)

Peer entry drops from system table silently when bootstrapping a node with an
existing IP.
--

Key: CASSANDRA-5565
URL: https://issues.apache.org/jira/browse/CASSANDRA-5565
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Reporter: Rick Branson

[jira] [Created] (CASSANDRA-5568) Invalid tracing info for execute_prepared_cql3_query

2013-05-14 Thread Pierre Chalamet (JIRA)

Pierre Chalamet created CASSANDRA-5568:
--

 Summary: Invalid tracing info for execute_prepared_cql3_query
 Key: CASSANDRA-5568
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5568
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.4
 Environment: Windows 8 x64
Java HotSpot(TM) 64-Bit Server VM/1.7.0_11
Reporter: Pierre Chalamet
Priority: Minor


When using trace_next_query() then execute_prepared_cql3_query(), it looks like 
tracing info are invalid (number of sessions/events and columns values are 
wrong).

How to reproduce:
{code}
create keyspace Tests with replication = {'class': 'SimpleStrategy', 
'replication_factor' : 1}
create table Tests.stresstest (strid varchar,intid int, primary key (strid))
{code}

and then executing the following prepared query 50,000 times:
{code}
insert into Tests.stresstest (intid, strid) values (?, ?)
{code}

produces the following results:
{code}
localhost select count(*) from Tests.stresstest
++
| count  |
++
| 5  |
++
localhost select count(*) from system_traces.events
++
| count  |
++
| 20832  |
++
localhost select count(*) from system_traces.sessions
++
| count  |
++
| 26717  |
++
localhost select * from system_traces.sessions limit 10
+--+-+--++-+---+
| sessionid| coordinator | duration | 
parameters | request | startedat |
+==+=+==++=+===+
| 9aefc263-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  |   
 | execute_prepared_cql3_query | 5/14/2013 9:16:55 PM  |
+--+-+--++-+---+
| 9ce0bcf7-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  |   
 | execute_prepared_cql3_query | 5/14/2013 9:16:59 PM  |
+--+-+--++-+---+
| 9dbe4ba4-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  |   
 | execute_prepared_cql3_query | 5/14/2013 9:17:00 PM  |
+--+-+--++-+---+
| 9d4d3a54-bcdb-11e2-8c60-fb495ee6a12c | | 44   |   
 | |   |
+--+-+--++-+---+
| 9a790bc1-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  |   
 | execute_prepared_cql3_query | 5/14/2013 9:16:55 PM  |
+--+-+--++-+---+
| 9c992c98-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  |   
 | execute_prepared_cql3_query | 5/14/2013 9:16:58 PM  |
+--+-+--++-+---+
| 9e27e2f6-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   | 53   |   
 | execute_prepared_cql3_query | 5/14/2013 9:17:01 PM  |
+--+-+--++-+---+
| 9b172074-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  |   
 | execute_prepared_cql3_query | 5/14/2013 9:16:56 PM  |
+--+-+--++-+---+
| 9a7cdc53-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   | 53   |   
 | execute_prepared_cql3_query | 5/14/2013 9:16:55 PM  |
+--+-+--++-+---+
| 9b6eb654-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  |   
 | execute_prepared_cql3_query | 5/14/2013 9:16:56 PM  |

[jira] [Updated] (CASSANDRA-5568) Invalid tracing info for execute_prepared_cql3_query


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

Jonathan Ellis updated CASSANDRA-5568:
--

Affects Version/s: (was: 1.2.4)
   1.2.0
Fix Version/s: 1.2.5

 Invalid tracing info for execute_prepared_cql3_query
 

 Key: CASSANDRA-5568
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5568
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
 Environment: Windows 8 x64
 Java HotSpot(TM) 64-Bit Server VM/1.7.0_11
Reporter: Pierre Chalamet
Priority: Minor
 Fix For: 1.2.5


 When using trace_next_query() then execute_prepared_cql3_query(), it looks 
 like tracing info are invalid (number of sessions/events and columns values 
 are wrong).
 How to reproduce:
 {code}
 create keyspace Tests with replication = {'class': 'SimpleStrategy', 
 'replication_factor' : 1}
 create table Tests.stresstest (strid varchar,intid int, primary key (strid))
 {code}
 and then executing the following prepared query 50,000 times:
 {code}
 insert into Tests.stresstest (intid, strid) values (?, ?)
 {code}
 produces the following results:
 {code}
 localhost select count(*) from Tests.stresstest
 ++
 | count  |
 ++
 | 5  |
 ++
 localhost select count(*) from system_traces.events
 ++
 | count  |
 ++
 | 20832  |
 ++
 localhost select count(*) from system_traces.sessions
 ++
 | count  |
 ++
 | 26717  |
 ++
 localhost select * from system_traces.sessions limit 10
 +--+-+--++-+---+
 | sessionid| coordinator | duration | 
 parameters | request | startedat |
 +==+=+==++=+===+
 | 9aefc263-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  | 
| execute_prepared_cql3_query | 5/14/2013 9:16:55 PM  |
 +--+-+--++-+---+
 | 9ce0bcf7-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  | 
| execute_prepared_cql3_query | 5/14/2013 9:16:59 PM  |
 +--+-+--++-+---+
 | 9dbe4ba4-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  | 
| execute_prepared_cql3_query | 5/14/2013 9:17:00 PM  |
 +--+-+--++-+---+
 | 9d4d3a54-bcdb-11e2-8c60-fb495ee6a12c | | 44   | 
| |   |
 +--+-+--++-+---+
 | 9a790bc1-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  | 
| execute_prepared_cql3_query | 5/14/2013 9:16:55 PM  |
 +--+-+--++-+---+
 | 9c992c98-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  | 
| execute_prepared_cql3_query | 5/14/2013 9:16:58 PM  |
 +--+-+--++-+---+
 | 9e27e2f6-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   | 53   | 
| execute_prepared_cql3_query | 5/14/2013 9:17:01 PM  |
 +--+-+--++-+---+
 | 9b172074-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   |  | 
| execute_prepared_cql3_query | 5/14/2013 9:16:56 PM  |
 +--+-+--++-+---+
 | 9a7cdc53-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1   | 53   | 
| execute_prepared_cql3_query | 5/14/2013

git commit: Fix CQL3 CAS conditions check

2013-05-14 Thread aleksey

Updated Branches:
  refs/heads/trunk 2dcbf0673 - 793d58a19


Fix CQL3 CAS conditions check


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

Branch: refs/heads/trunk
Commit: 793d58a197eded203a7bae5ec49c60d347eb2d14
Parents: 2dcbf06
Author: Aleksey Yeschenko alek...@apache.org
Authored: Wed May 15 01:05:20 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 15 01:05:20 2013 +0300

--
 .../cql3/statements/ModificationStatement.java |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/793d58a1/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
index 7ca..45fbecc 100644
--- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
@@ -476,7 +476,7 @@ public abstract class ModificationStatement implements 
CQLStatement
 
 ModificationStatement stmt = prepareInternal(cfDef, boundNames);
 
-if (stmt.hasConditions())
+if (ifNotExists || (conditions != null  !conditions.isEmpty()))
 {
 if (stmt.isCounter())
 throw new InvalidRequestException(Conditional updates are 
not supported on counter tables);

[jira] [Resolved] (CASSANDRA-5443) Add CAS CQL support

2013-05-14 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko resolved CASSANDRA-5443.
--

Resolution: Fixed

stmt.hasConditions() check in ModificationStatement.Parsed.prepare() was always 
returning false, since stmt.ifNotExists and stmt.columnConditions were always 
false/null at that point. Fixed in 793d58a197eded203a7bae5ec49c60d347eb2d14.

 Add CAS CQL support
 ---

 Key: CASSANDRA-5443
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5443
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
 Fix For: 2.0

 Attachments: 
 0001-Refactor-Update-and-Delete-statement-to-extract-common.txt, 
 0002-Add-syntax-to-support-conditional-update-delete.txt, 
 0003-Handle-deleted-and-expiring-column-in-paxos-updates.txt, 
 0004-Support-tombstones-when-comparing-for-CAS.txt, 
 0005-add-UPDATE-.-IF-NOT-EXISTS-syntax.txt, 
 0006-Make-EXISTS-a-reserverd-keyword.txt




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5443) Add CAS CQL support

2013-05-14 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko commented on CASSANDRA-5443:
--

(we accidentally broke it in 
https://github.com/apache/cassandra/commit/2f3f620e while fixing counter 
updates)

 Add CAS CQL support
 ---

 Key: CASSANDRA-5443
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5443
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
 Fix For: 2.0

 Attachments: 
 0001-Refactor-Update-and-Delete-statement-to-extract-common.txt, 
 0002-Add-syntax-to-support-conditional-update-delete.txt, 
 0003-Handle-deleted-and-expiring-column-in-paxos-updates.txt, 
 0004-Support-tombstones-when-comparing-for-CAS.txt, 
 0005-add-UPDATE-.-IF-NOT-EXISTS-syntax.txt, 
 0006-Make-EXISTS-a-reserverd-keyword.txt




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat

2013-05-14 Thread Mike Schrag (JIRA)


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

Mike Schrag commented on CASSANDRA-4421:


Alex - would you expect to get duplicate rows out of this code? I wasn't sure 
if I need to dedupe multiple results due to replication factor  1. I'm seeing 
some weird stuff with a large table (nominally should be about 50 million rows) 
that has been truncate and recreated, and we're up to 500 million rows dumped 
out of it so far. I'm not quite sure what I'm seeing, yet, but just wanted to 
explore what the expected behavior is.

 Support cql3 table definitions in Hadoop InputFormat
 

 Key: CASSANDRA-4421
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4421
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Affects Versions: 1.1.0
 Environment: Debian Squeeze
Reporter: bert Passek
  Labels: cql3
 Fix For: 1.2.5

 Attachments: 4421-1.txt, 4421-2.txt, 4421.txt


 Hello,
 i faced a bug while writing composite column values and following validation 
 on server side.
 This is the setup for reproduction:
 1. create a keyspace
 create keyspace test with strategy_class = 'SimpleStrategy' and 
 strategy_options:replication_factor = 1;
 2. create a cf via cql (3.0)
 create table test1 (
 a int,
 b int,
 c int,
 primary key (a, b)
 );
 If i have a look at the schema in cli i noticed that there is no column 
 metadata for columns not part of primary key.
 create column family test1
   with column_type = 'Standard'
   and comparator = 
 'CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.UTF8Type)'
   and default_validation_class = 'UTF8Type'
   and key_validation_class = 'Int32Type'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and gc_grace = 864000
   and min_compaction_threshold = 4
   and max_compaction_threshold = 32
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and compression_options = {'sstable_compression' : 
 'org.apache.cassandra.io.compress.SnappyCompressor'};
 Please notice the default validation class: UTF8Type
 Now i would like to insert value  127 via cassandra client (no cql, part of 
 mr-jobs). Have a look at the attachement.
 Batch mutate fails:
 InvalidRequestException(why:(String didn't validate.) [test][test1][1:c] 
 failed validation)
 A validator for column value is fetched in 
 ThriftValidation::validateColumnData which returns always the default 
 validator which is UTF8Type as described above (The ColumnDefinition for 
 given column name c is always null)
 In UTF8Type there is a check for
 if (b  127)
return false;
 Anyway, maybe i'm doing something wrong, but i used cql 3.0 for table 
 creation. I assigned data types to all columns, but i can not set values for 
 a composite column because the default validation class is used.
 I think the schema should know the correct validator even for composite 
 columns. The usage of the default validation class does not make sense.
 Best Regards 
 Bert Passek

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-5569) Every stream operation requires checking indexes in every SSTable

Rick Branson created CASSANDRA-5569:
---

 Summary: Every stream operation requires checking indexes in every 
SSTable
 Key: CASSANDRA-5569
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5569
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.4
Reporter: Rick Branson
Assignee: Rick Branson
 Fix For: 1.2.4


It looks like there's a streaming performance issue when leveled compaction and 
vnodes get together. To get the candidate set of chunks to stream, the 
streaming system gets references to every SSTable for a CF. This is probably a 
perfectly reasonable assumption for non-vnode cases, because the data being 
streamed is likely distributed across the full SSTable set. This is also 
probably a perfectly reasonable assumption for size-tiered compaction, because 
the data is, again, likely distributed across the full SSTable set. However, 
for each vnode repair performed on LCS CF's, this scan across potentially tens 
of thousands of SSTables is wasteful considering that only a small percentage 
of them will actually have data for a given range.

This manifested itself as hanging repair operations with tasks backing up on 
the MiscStage thread pool.

The attached patch changes the streaming code so that for a given range, only 
SSTables for the requested range are checked to be included in streaming.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5569) Every stream operation requires checking indexes in every SSTable


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

Rick Branson updated CASSANDRA-5569:


Attachment: 5569.txt

 Every stream operation requires checking indexes in every SSTable
 -

 Key: CASSANDRA-5569
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5569
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.4
Reporter: Rick Branson
Assignee: Rick Branson
 Fix For: 1.2.4

 Attachments: 5569.txt


 It looks like there's a streaming performance issue when leveled compaction 
 and vnodes get together. To get the candidate set of chunks to stream, the 
 streaming system gets references to every SSTable for a CF. This is probably 
 a perfectly reasonable assumption for non-vnode cases, because the data being 
 streamed is likely distributed across the full SSTable set. This is also 
 probably a perfectly reasonable assumption for size-tiered compaction, 
 because the data is, again, likely distributed across the full SSTable set. 
 However, for each vnode repair performed on LCS CF's, this scan across 
 potentially tens of thousands of SSTables is wasteful considering that only a 
 small percentage of them will actually have data for a given range.
 This manifested itself as hanging repair operations with tasks backing up 
 on the MiscStage thread pool.
 The attached patch changes the streaming code so that for a given range, only 
 SSTables for the requested range are checked to be included in streaming.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5455) Remove PBSPredictor

2013-05-14 Thread Peter Bailis (JIRA)

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

Peter Bailis commented on CASSANDRA-5455:
-

I've thought some more about different options for enabling metrics that are
useful to both PBS (in an external module, if committers prefer) and anyone
else who would be interested in finer-grained tracing.

To start, I *do* think that there is interest in a PBS module: if an eventually
consistent store is returning stale data, how stale *is* it? Especially given
that many (most?) Cassandra client libraries (including the Datastax
java-driver) choose CL=ONE by default, I'd expect most users would prefer to
understand how their choice of N,R, and W affects their latency and consistency.

I've been contacted by several Cassandra users who are interested in and/or
using this functionality and understand that several developers are interested
in PBS for Riak (notably, Andy Gross highlighted PBS in his 2013 RICON East
keynote as a useful feature Basho would like). We originally chose Cassandra
based on our familiarity with the code base and on early discussions with
Jonathan but we plan to integrate PBS functionality into Riak with the help of
their committers in the near-term future. So I do think there is interest, and,
if you're curious about *use cases* for this functionality, Shivaram and I will
be demoing PBS in Cassandra 1.2 at the upcoming SIGMOD 2013 conference. Our
demo proposal sketches three application vignettes, including the obvious
integration with monitoring tools but also automatically tuning N,R, and W and
and providing consistency and latency SLAs:
http://www.bailis.org/papers/pbs-demo-sigmod2013.pdf

So, on the more technical side, there are two statistics that aren't currently
measured (in trunk) that are required for accurate PBS predictions. First, PBS
requires per-server statistics. Currently, the ColumnFamily RTT read/write
latency metrics are aggregated across all servers. Second, PBS requires a
measure how how long a read/write request takes before it is processed (i.e.,
how long it took from a client sending each read/write request to when it was
performed). This requires knowledge of one-way request latencies as well as
read/write request-specific logic.

The 1.2 PBS patch provided both of these, aggregating by server and measuring
the delay until processing. As Jonathan notes above, the latter measurement was
conservative--the remote replica recorded the time that it enqueued its
response rather than the exact moment a read or write was performed, namely for
simplicity of code. The coordinating server could then closely approximate the
return time as RTT-(remote timestamp).

Given these requirements and the current state of trunk, there are a few ways
forward to support an external PBS prediction module:

1a.) Modify Cassandra to store latency statistics on a per-server and
per-ColumnFamily granularity. As Rick Branson has pointed out, this is actually
useful for monitoring other than PBS and can be used to detect slower replicas.

1b.) Modify Cassandra to store local processing times for requests (i.e.,
expand StorageMetrics, which currently does not track the time required to,
say, fulfill a local read stage). This also has the benefit of understanding
whether a Cassandra node is slow due to network or disk.

2.) Use the newly developed tracing functionality to reconstruct latencies for
selected requests. Performing any sort of profiling will require tracing to be
enabled (this appears to be somewhat heavyweight given the amount of data that
is logged for each request , and reconstructing latencies from the trace table
may be expensive (i.e., amount to a many-way self-join).

3.) Use RTT/2 based on ColumnFamily LatencyMetrics as an inaccurate but already
supported external predictor.

4.) Leave the PBS latency sampling as in 1.2 but remove the PBS predictor code.
Expose the latency samples via an Mbean for users like Rick who would benefit
from it.

Proposal #1 has benefits for many users and seems a natural extension to the
existing metrics but requires changes to the existing code. Proposal #2 puts
substantial burden on an end-user and, without a fixed schema for the trace
table, may amount to a fair bit of code munging. Proposal #3 is inaccurate but
works on trunk. Proposal #4 is essentially 1.2.0 without the requirement to
maintain any PBS-specific code and is a reasonable stop-gap before proposal #1.
All of these proposals are amenable to sampling.

I'd welcome your feedback on these proposals and next steps.

Remove PBSPredictor
---

Key: CASSANDRA-5455
URL: https://issues.apache.org/jira/browse/CASSANDRA-5455
Project: Cassandra
Issue Type: Bug
Reporter: Jonathan

[jira] [Comment Edited] (CASSANDRA-5455) Remove PBSPredictor

2013-05-14 Thread Peter Bailis (JIRA)

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

Peter Bailis edited comment on CASSANDRA-5455 at 5/14/13 11:48 PM:
---

The 1.2 PBS patch provided both of these, aggregating by server and measuring
the delay until processing. As Jonathan notes above, the latter measurement was
conservative; the remote replica recorded the time that it enqueued its
response rather than the exact moment a read or write was performed, namely for
simplicity of code. The coordinating server could then closely approximate the
return time as RTT-(remote timestamp).

Given these requirements and the current state of trunk, there are a few ways
forward to support an external PBS prediction module:

3.) Use RTT/2 based on ColumnFamily LatencyMetrics as an inaccurate but already
supported external predictor.

4.) Leave the PBS latency sampling as in 1.2 but remove the PBS predictor code.
Expose the latency samples via an Mbean for users like Rick who would benefit
from it.

I'd welcome your feedback on these proposals and next steps.

was (Author: pbailis):
I've thought some more about different options for enabling metrics that
are useful to both PBS (in an external module, if committers prefer) and anyone
else

[jira] [Assigned] (CASSANDRA-5565) Peer entry drops from system table silently when bootstrapping a node with an existing IP.


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

Brandon Williams reassigned CASSANDRA-5565:
---

Assignee: Brandon Williams

 Peer entry drops from system table silently when bootstrapping a node with an 
 existing IP.
 --

 Key: CASSANDRA-5565
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5565
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.4
Reporter: Rick Branson
Assignee: Brandon Williams

 It looks like CASSANDRA-5167 introduced a bit of a regression. I needed to 
 rebuild the data on a malfunctioning node by rebootstrapping it. I did this 
 by cleaning the host and restarting Cassandra. My plan was to remove the old 
 hostID once it had successfully bootstrapped. 
 No errors were encountered, but the old host ID of the node before the wipe 
 was completely dropped from the peers table because they had the same IP 
 address, and therefore the data ranges were moved around. This resulted in a 
 large number of CL.ONE reads coming back empty.
 There might be a better approach to this rebootstrap process, but it seems 
 like it's dangerous to just drop the peer from the table, especially without 
 any kind of log message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5567) DESCRIBE TABLES is empty after case insensitive use

2013-05-14 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko updated CASSANDRA-5567:
-

Attachment: 5567.txt

 DESCRIBE TABLES is empty after case insensitive use
 ---

 Key: CASSANDRA-5567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5567
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Mike Bulman
Assignee: Aleksey Yeschenko
Priority: Trivial
 Fix For: 1.2.5

 Attachments: 5567.txt


 Using trunk @ 02547747198c0d14f9a4102a920b914bcfd57a23
 {noformat}
 trunk*:~/src/cassandra$ bin/cqlsh -3
 Connected to Test Cluster at localhost:9160.
 [cqlsh 3.0.2 | Cassandra 2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 
 19.37.0]
 Use HELP for help.
 cqlsh create keyspace Test with replication={'class':'SimpleStrategy', 
 'replication_factor':1};
 cqlsh use Test;
 cqlsh:Test CREATE TABLE users (   user_name varchar PRIMARY KEY,   password 
 varchar,   gender varchar,   session_token varchar,   state varchar,   
 birth_year bigint );
 cqlsh:Test describe tables;
 empty
 cqlsh:Test use test;
 cqlsh:test describe tables;
 users
 cqlsh:test
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat

2013-05-14 Thread Mike Schrag (JIRA)


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

Mike Schrag commented on CASSANDRA-4421:


Also curious if there's any way I would get previously deleted rows back from 
this?

 Support cql3 table definitions in Hadoop InputFormat
 

 Key: CASSANDRA-4421
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4421
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Affects Versions: 1.1.0
 Environment: Debian Squeeze
Reporter: bert Passek
  Labels: cql3
 Fix For: 1.2.5

 Attachments: 4421-1.txt, 4421-2.txt, 4421.txt


 Hello,
 i faced a bug while writing composite column values and following validation 
 on server side.
 This is the setup for reproduction:
 1. create a keyspace
 create keyspace test with strategy_class = 'SimpleStrategy' and 
 strategy_options:replication_factor = 1;
 2. create a cf via cql (3.0)
 create table test1 (
 a int,
 b int,
 c int,
 primary key (a, b)
 );
 If i have a look at the schema in cli i noticed that there is no column 
 metadata for columns not part of primary key.
 create column family test1
   with column_type = 'Standard'
   and comparator = 
 'CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.UTF8Type)'
   and default_validation_class = 'UTF8Type'
   and key_validation_class = 'Int32Type'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and gc_grace = 864000
   and min_compaction_threshold = 4
   and max_compaction_threshold = 32
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and compression_options = {'sstable_compression' : 
 'org.apache.cassandra.io.compress.SnappyCompressor'};
 Please notice the default validation class: UTF8Type
 Now i would like to insert value  127 via cassandra client (no cql, part of 
 mr-jobs). Have a look at the attachement.
 Batch mutate fails:
 InvalidRequestException(why:(String didn't validate.) [test][test1][1:c] 
 failed validation)
 A validator for column value is fetched in 
 ThriftValidation::validateColumnData which returns always the default 
 validator which is UTF8Type as described above (The ColumnDefinition for 
 given column name c is always null)
 In UTF8Type there is a check for
 if (b  127)
return false;
 Anyway, maybe i'm doing something wrong, but i used cql 3.0 for table 
 creation. I assigned data types to all columns, but i can not set values for 
 a composite column because the default validation class is used.
 I think the schema should know the correct validator even for composite 
 columns. The usage of the default validation class does not make sense.
 Best Regards 
 Bert Passek

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5569) Every stream operation requires checking indexes in every SSTable


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

Jonathan Ellis commented on CASSANDRA-5569:
---

This could cause a lot of reference churn, can you make 
DataTracker.markReferenced take a list of Bounds objects instead so we can 
uniquify the set before acquiring references?

 Every stream operation requires checking indexes in every SSTable
 -

 Key: CASSANDRA-5569
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5569
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.4
Reporter: Rick Branson
Assignee: Rick Branson
 Fix For: 1.2.4

 Attachments: 5569.txt


 It looks like there's a streaming performance issue when leveled compaction 
 and vnodes get together. To get the candidate set of chunks to stream, the 
 streaming system gets references to every SSTable for a CF. This is probably 
 a perfectly reasonable assumption for non-vnode cases, because the data being 
 streamed is likely distributed across the full SSTable set. This is also 
 probably a perfectly reasonable assumption for size-tiered compaction, 
 because the data is, again, likely distributed across the full SSTable set. 
 However, for each vnode repair performed on LCS CF's, this scan across 
 potentially tens of thousands of SSTables is wasteful considering that only a 
 small percentage of them will actually have data for a given range.
 This manifested itself as hanging repair operations with tasks backing up 
 on the MiscStage thread pool.
 The attached patch changes the streaming code so that for a given range, only 
 SSTables for the requested range are checked to be included in streaming.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5569) Every stream operation requires checking indexes in every SSTable


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

Jonathan Ellis updated CASSANDRA-5569:
--

 Reviewer: jbellis
 Priority: Minor  (was: Major)
Affects Version/s: (was: 1.2.4)
   1.2.0
Fix Version/s: (was: 1.2.4)
   1.2.5
   Labels: streaming  (was: )

 Every stream operation requires checking indexes in every SSTable
 -

 Key: CASSANDRA-5569
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5569
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
Reporter: Rick Branson
Assignee: Rick Branson
Priority: Minor
  Labels: streaming
 Fix For: 1.2.5

 Attachments: 5569.txt


 It looks like there's a streaming performance issue when leveled compaction 
 and vnodes get together. To get the candidate set of chunks to stream, the 
 streaming system gets references to every SSTable for a CF. This is probably 
 a perfectly reasonable assumption for non-vnode cases, because the data being 
 streamed is likely distributed across the full SSTable set. This is also 
 probably a perfectly reasonable assumption for size-tiered compaction, 
 because the data is, again, likely distributed across the full SSTable set. 
 However, for each vnode repair performed on LCS CF's, this scan across 
 potentially tens of thousands of SSTables is wasteful considering that only a 
 small percentage of them will actually have data for a given range.
 This manifested itself as hanging repair operations with tasks backing up 
 on the MiscStage thread pool.
 The attached patch changes the streaming code so that for a given range, only 
 SSTables for the requested range are checked to be included in streaming.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat

2013-05-14 Thread Alex Liu (JIRA)


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

Alex Liu commented on CASSANDRA-4421:
-

[~mikeschrag] If CQL3 statement provided in hadoop job doesn't return duplicate 
rows then the hadoop job shouldn't return duplicate rows. But CQL 3 doesn't 
have DISTINCT key word support, so some CQL3 query returns duplicate rows.

You can test it at one node to see whether the duplicate rows occur, then test 
it for multiple nodes with rp  1.

RF shouldn't create duplicate rows. Let's trace it or reproduce it in a simple 
way.



 Support cql3 table definitions in Hadoop InputFormat
 

 Key: CASSANDRA-4421
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4421
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Affects Versions: 1.1.0
 Environment: Debian Squeeze
Reporter: bert Passek
  Labels: cql3
 Fix For: 1.2.5

 Attachments: 4421-1.txt, 4421-2.txt, 4421.txt


 Hello,
 i faced a bug while writing composite column values and following validation 
 on server side.
 This is the setup for reproduction:
 1. create a keyspace
 create keyspace test with strategy_class = 'SimpleStrategy' and 
 strategy_options:replication_factor = 1;
 2. create a cf via cql (3.0)
 create table test1 (
 a int,
 b int,
 c int,
 primary key (a, b)
 );
 If i have a look at the schema in cli i noticed that there is no column 
 metadata for columns not part of primary key.
 create column family test1
   with column_type = 'Standard'
   and comparator = 
 'CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.UTF8Type)'
   and default_validation_class = 'UTF8Type'
   and key_validation_class = 'Int32Type'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and gc_grace = 864000
   and min_compaction_threshold = 4
   and max_compaction_threshold = 32
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and compression_options = {'sstable_compression' : 
 'org.apache.cassandra.io.compress.SnappyCompressor'};
 Please notice the default validation class: UTF8Type
 Now i would like to insert value  127 via cassandra client (no cql, part of 
 mr-jobs). Have a look at the attachement.
 Batch mutate fails:
 InvalidRequestException(why:(String didn't validate.) [test][test1][1:c] 
 failed validation)
 A validator for column value is fetched in 
 ThriftValidation::validateColumnData which returns always the default 
 validator which is UTF8Type as described above (The ColumnDefinition for 
 given column name c is always null)
 In UTF8Type there is a check for
 if (b  127)
return false;
 Anyway, maybe i'm doing something wrong, but i used cql 3.0 for table 
 creation. I assigned data types to all columns, but i can not set values for 
 a composite column because the default validation class is used.
 I think the schema should know the correct validator even for composite 
 columns. The usage of the default validation class does not make sense.
 Best Regards 
 Bert Passek

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat

2013-05-14 Thread Alex Liu (JIRA)


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

Alex Liu commented on CASSANDRA-4421:
-

If you have some snapshot of the nodes, you can restore them, otherwise you 
will lose the deleted rows after compaction.

 Support cql3 table definitions in Hadoop InputFormat
 

 Key: CASSANDRA-4421
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4421
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Affects Versions: 1.1.0
 Environment: Debian Squeeze
Reporter: bert Passek
  Labels: cql3
 Fix For: 1.2.5

 Attachments: 4421-1.txt, 4421-2.txt, 4421.txt


 Hello,
 i faced a bug while writing composite column values and following validation 
 on server side.
 This is the setup for reproduction:
 1. create a keyspace
 create keyspace test with strategy_class = 'SimpleStrategy' and 
 strategy_options:replication_factor = 1;
 2. create a cf via cql (3.0)
 create table test1 (
 a int,
 b int,
 c int,
 primary key (a, b)
 );
 If i have a look at the schema in cli i noticed that there is no column 
 metadata for columns not part of primary key.
 create column family test1
   with column_type = 'Standard'
   and comparator = 
 'CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.UTF8Type)'
   and default_validation_class = 'UTF8Type'
   and key_validation_class = 'Int32Type'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and gc_grace = 864000
   and min_compaction_threshold = 4
   and max_compaction_threshold = 32
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and compression_options = {'sstable_compression' : 
 'org.apache.cassandra.io.compress.SnappyCompressor'};
 Please notice the default validation class: UTF8Type
 Now i would like to insert value  127 via cassandra client (no cql, part of 
 mr-jobs). Have a look at the attachement.
 Batch mutate fails:
 InvalidRequestException(why:(String didn't validate.) [test][test1][1:c] 
 failed validation)
 A validator for column value is fetched in 
 ThriftValidation::validateColumnData which returns always the default 
 validator which is UTF8Type as described above (The ColumnDefinition for 
 given column name c is always null)
 In UTF8Type there is a check for
 if (b  127)
return false;
 Anyway, maybe i'm doing something wrong, but i used cql 3.0 for table 
 creation. I assigned data types to all columns, but i can not set values for 
 a composite column because the default validation class is used.
 I think the schema should know the correct validator even for composite 
 columns. The usage of the default validation class does not make sense.
 Best Regards 
 Bert Passek

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5569) Every stream operation requires checking indexes in every SSTable


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

Rick Branson commented on CASSANDRA-5569:
-

How do you feel about the safety of refactoring the markReferenced(RowPosition 
start, RowPosition end) signature call the new markReferenced to cut down on 
the duplication between these methods?

 Every stream operation requires checking indexes in every SSTable
 -

 Key: CASSANDRA-5569
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5569
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
Reporter: Rick Branson
Assignee: Rick Branson
Priority: Minor
  Labels: streaming
 Fix For: 1.2.5

 Attachments: 5569.txt


 It looks like there's a streaming performance issue when leveled compaction 
 and vnodes get together. To get the candidate set of chunks to stream, the 
 streaming system gets references to every SSTable for a CF. This is probably 
 a perfectly reasonable assumption for non-vnode cases, because the data being 
 streamed is likely distributed across the full SSTable set. This is also 
 probably a perfectly reasonable assumption for size-tiered compaction, 
 because the data is, again, likely distributed across the full SSTable set. 
 However, for each vnode repair performed on LCS CF's, this scan across 
 potentially tens of thousands of SSTables is wasteful considering that only a 
 small percentage of them will actually have data for a given range.
 This manifested itself as hanging repair operations with tasks backing up 
 on the MiscStage thread pool.
 The attached patch changes the streaming code so that for a given range, only 
 SSTables for the requested range are checked to be included in streaming.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5567) DESCRIBE TABLES is empty after case insensitive use


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

Brandon Williams commented on CASSANDRA-5567:
-

+1

 DESCRIBE TABLES is empty after case insensitive use
 ---

 Key: CASSANDRA-5567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5567
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Mike Bulman
Assignee: Aleksey Yeschenko
Priority: Trivial
 Fix For: 1.2.5

 Attachments: 5567.txt


 Using trunk @ 02547747198c0d14f9a4102a920b914bcfd57a23
 {noformat}
 trunk*:~/src/cassandra$ bin/cqlsh -3
 Connected to Test Cluster at localhost:9160.
 [cqlsh 3.0.2 | Cassandra 2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 
 19.37.0]
 Use HELP for help.
 cqlsh create keyspace Test with replication={'class':'SimpleStrategy', 
 'replication_factor':1};
 cqlsh use Test;
 cqlsh:Test CREATE TABLE users (   user_name varchar PRIMARY KEY,   password 
 varchar,   gender varchar,   session_token varchar,   state varchar,   
 birth_year bigint );
 cqlsh:Test describe tables;
 empty
 cqlsh:Test use test;
 cqlsh:test describe tables;
 users
 cqlsh:test
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5569) Every stream operation requires checking indexes in every SSTable


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

Jonathan Ellis commented on CASSANDRA-5569:
---

+1

 Every stream operation requires checking indexes in every SSTable
 -

 Key: CASSANDRA-5569
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5569
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
Reporter: Rick Branson
Assignee: Rick Branson
Priority: Minor
  Labels: streaming
 Fix For: 1.2.5

 Attachments: 5569.txt


 It looks like there's a streaming performance issue when leveled compaction 
 and vnodes get together. To get the candidate set of chunks to stream, the 
 streaming system gets references to every SSTable for a CF. This is probably 
 a perfectly reasonable assumption for non-vnode cases, because the data being 
 streamed is likely distributed across the full SSTable set. This is also 
 probably a perfectly reasonable assumption for size-tiered compaction, 
 because the data is, again, likely distributed across the full SSTable set. 
 However, for each vnode repair performed on LCS CF's, this scan across 
 potentially tens of thousands of SSTables is wasteful considering that only a 
 small percentage of them will actually have data for a given range.
 This manifested itself as hanging repair operations with tasks backing up 
 on the MiscStage thread pool.
 The attached patch changes the streaming code so that for a given range, only 
 SSTables for the requested range are checked to be included in streaming.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5569) Every stream operation requires checking indexes in every SSTable