[jira] [Commented] (CASSANDRA-4795) replication, compaction, compression? options are not validated

2013-02-12 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-4795:
-

bq. If the original intention was to protect people from mistypes

How can that *not* be one's intent?

bq. like git does e.g. option rplicatian_factor is not recognized maybe you 
mean 'replication_factor'?

Sure, that would be great: reject errors with fix suggestion in the error 
message is indeed even better than reject errors that is itself better than 
not reject errors silently. So be my guest, do open a ticket to do even 
better than what this patch does. But that patch is still progress.

bq. it's pretty convenient to keep it in the keypsace strategy options (without 
have any other alternatives)

Again, I'm ok talking about alternatives that would be right if there is a 
need, but you will not convince me that shoving random application data inside 
the strategy options is right, or even a good idea.


 replication, compaction, compression? options are not validated
 ---

 Key: CASSANDRA-4795
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4795
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Brandon Williams
Assignee: Dave Brosius
Priority: Minor
 Fix For: 1.2.1

 Attachments: 4795.compaction_strategy.txt, 
 4795_compaction_strategy_v2.txt, 4795_compaction_strategy_v3.txt, 
 4795.replication_strategy.txt


 When creating a keyspace and specifying strategy options, you can pass any 
 k/v pair you like.

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


[Cassandra Wiki] Trivial Update of GlennMore by GlennMore

2013-02-12 Thread Apache Wiki
Dear Wiki user,

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

The GlennMore page has been changed by GlennMore:
http://wiki.apache.org/cassandra/GlennMore?action=diffrev1=3rev2=4

- Hey !! The name is EVAN WOODARD. This spring iam going to be 53.BR
- I like Legos. My daddy name is Dan and he is a Stage Designer. My momy is a 
Bookbinder.BR
+ Yo guys !! The name is OLENE HILL. This feb i will be 40.BR
+ I also like to Artwork. My papa name is Ryan and he is a Lifeguard. My mother 
is a Engine-driver.BR
  BR
- Also visit my web site :: [[http://www.fairchanelstore.com|chanel purse]]
+ my blog post [[http://www.fairchanelstore.com|chanel wallet]]
  


[jira] [Commented] (CASSANDRA-4795) replication, compaction, compression? options are not validated

2013-02-12 Thread Pavel Yaskevich (JIRA)

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

Pavel Yaskevich commented on CASSANDRA-4795:


I don't think this is about right or wrong but rather about living by means 
instead of re-inventing broken bicycle. I'm not arguing or trying to convince, 
I'm simply saying that committed patch made situation even worse and it should 
be reconsidered all together. Also, if somebody ever had mistyped and didn't 
fix or used unrecognized attributes in replication strategy or compaction, 
after upgrade to 1.2.1 Cassandra just *wouldn't start up* which is also a 
ridiculously bad user experience, this is why I think this patch should be 
reverted.

 replication, compaction, compression? options are not validated
 ---

 Key: CASSANDRA-4795
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4795
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Brandon Williams
Assignee: Dave Brosius
Priority: Minor
 Fix For: 1.2.1

 Attachments: 4795.compaction_strategy.txt, 
 4795_compaction_strategy_v2.txt, 4795_compaction_strategy_v3.txt, 
 4795.replication_strategy.txt


 When creating a keyspace and specifying strategy options, you can pass any 
 k/v pair you like.

--
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-4795) replication, compaction, compression? options are not validated

2013-02-12 Thread Pavel Yaskevich (JIRA)

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

Pavel Yaskevich edited comment on CASSANDRA-4795 at 2/12/13 8:19 AM:
-

I don't think this is about right or wrong but rather about living by means 
instead of re-inventing broken bicycle. I'm not arguing or trying to convince, 
I'm simply saying that committed patch made situation even worse and it should 
be reconsidered all together. Also, if somebody ever had mistyped and didn't 
fix or used unrecognized attributes in replication strategy or compaction, 
after upgrade to 1.2.1 Cassandra just *wouldn't start up* which is also a 
ridiculously bad user experience, this is why I think this patch should be 
reverted.

Edit: I think that concerns DSE as well, because AFAIK they used custom 
attributes in the compaction strategy as well as in keyspace replication.

  was (Author: xedin):
I don't think this is about right or wrong but rather about living by means 
instead of re-inventing broken bicycle. I'm not arguing or trying to convince, 
I'm simply saying that committed patch made situation even worse and it should 
be reconsidered all together. Also, if somebody ever had mistyped and didn't 
fix or used unrecognized attributes in replication strategy or compaction, 
after upgrade to 1.2.1 Cassandra just *wouldn't start up* which is also a 
ridiculously bad user experience, this is why I think this patch should be 
reverted.
  
 replication, compaction, compression? options are not validated
 ---

 Key: CASSANDRA-4795
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4795
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Brandon Williams
Assignee: Dave Brosius
Priority: Minor
 Fix For: 1.2.1

 Attachments: 4795.compaction_strategy.txt, 
 4795_compaction_strategy_v2.txt, 4795_compaction_strategy_v3.txt, 
 4795.replication_strategy.txt


 When creating a keyspace and specifying strategy options, you can pass any 
 k/v pair you like.

--
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: Versions, news and changelog updates for 1.1.10 release

2013-02-12 Thread slebresne
Updated Branches:
  refs/heads/cassandra-1.1 577cb2c76 - 684994215


Versions, news and changelog updates for 1.1.10 release


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

Branch: refs/heads/cassandra-1.1
Commit: 684994215120b2bac4e04f520420e105e21d07c9
Parents: 577cb2c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 12 08:37:43 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 12 08:37:43 2013 +0100

--
 CHANGES.txt  |3 +++
 NEWS.txt |8 
 build.xml|2 +-
 debian/changelog |6 ++
 4 files changed, 18 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0c76bd0..1ef799f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -6,6 +6,9 @@
  * add ConfigHelper support for Thrift frame and max message sizes 
(CASSANDRA-5188)
  * fix nodetool repair not fail on node down (CASSANDRA-5203)
  * always collect tombstone hints (CASSANDRA-5068)
+ * Fix thread growth on node removal (CASSANDRA-5175)
+ * Fix error when sourcing file in cqlsh (CASSANDRA-5235)
+ * Make Ec2Region's datacenter name configurable (CASSANDRA-5155)
 
 
 1.1.9

http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 04da469..b8954d4 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -8,6 +8,14 @@ upgrade, just in case you need to roll back to the previous 
version.
 (Cassandra version X + 1 will always be able to read data files created
 by version X, but the inverse is not necessarily the case.)
 
+1.1.10
+==
+
+Upgrading
+-
+- Nothing specific to this release, but please see the previous 
instructions
+  if you are not upgrading from 1.1.9.
+
 1.1.9
 =
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/build.xml
--
diff --git a/build.xml b/build.xml
index 1ca323d..6fa5172 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 property name=debuglevel value=source,lines,vars/
 
 !-- default version and SCM information --
-property name=base.version value=1.1.9/
+property name=base.version value=1.1.10/
 property name=scm.connection 
value=scm:git://git.apache.org/cassandra.git/
 property name=scm.developerConnection 
value=scm:git://git.apache.org/cassandra.git/
 property name=scm.url 
value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/

http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 445e3bf..46d1781 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (1.1.10) unstable; urgency=low
+
+  * New release
+
+ -- Sylvain Lebresne slebre...@apache.org  Tue, 12 Feb 2013 08:36:19 +0100
+
 cassandra (1.1.9) unstable; urgency=low
 
   * New release



Git Push Summary

2013-02-12 Thread slebresne
Updated Tags:  refs/tags/1.1.10-tentative [created] 684994215


[jira] [Commented] (CASSANDRA-5239) Fully Aysnc Server Transport (StorageProxy Layer)

2013-02-12 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-5239:
-

As said in CASSANDRA-4277, I'm actually very much in favor of having SP be 
async for the binary protocol sake. And now that I think about it more clearly, 
I actually agree it may not be that hard (there's the question of the timeouts, 
but we can use timers, though we may want to look at things like netty's 
HashedWheelTimer for efficiency sake).

This would definitively be great for the binary protocol. However, for Thrift, 
I'm on Jonathan's side, I'm not really interested.

 Fully Aysnc Server Transport (StorageProxy Layer)
 -

 Key: CASSANDRA-5239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5239
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0
Reporter: Vijay
Assignee: Vijay
Priority: Minor
 Fix For: 2.0


 Problem Statement: 
 Currently we have rpc_min_threads, rpc_max_threads/ 
 native_transport_min_threads/native_transport_max_threads all of the 
 threads in the TPE are blocking and takes resources, the threads are mostly 
 sleeping. Increasing the Context switch costs.
 Details: 
 We should change StorageProxy methods to provide a callback which contains 
 the location where the results has to be written. When the response arrive 
 StorageProxy callback can write the results directly into the connection. 
 Timeouts can be handled in the same way.
 Fixing Netty should be trivial with some refactor in the storage proxy 
 (currently it is one method call for sending the request and waiting) we need 
 callback.
 Fixing Thrift may be harder because thrift calls the method and expects a 
 return value. We might need to write a custom Codec on Netty for thrift 
 support, which can potentially do callbacks (A Custom codec may be similar to 
 http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html
  but we dont know details about it). Another option is to update thrift to 
 have a callback.
 FYI, The motivation for this ticket is from another project which i am 
 working on with similar Proxy (blocking Netty transport) and making it Async 
 gave us 2x throughput improvement.

--
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-3014) AnitEntropy/MerkleTree Error

2013-02-12 Thread JIRA

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

David Röhr commented on CASSANDRA-3014:
---

Another repro in 1.2.1.
6 nodes cluster (vnodes, murmur3, rf:3)
very low activity
running a nodetool repair -pr loop on the cluster nodes

nodetool hangs, and same big stacktrace in logs. 

root 11025  0.0  0.0 106100  1436 pts/0S+   Feb11   0:00  \_ 
/bin/sh /usr/bin/nodetool -h HOST -p 7199 -pr repair KEYSPACE COLUMN_FAMILY

 AnitEntropy/MerkleTree Error
 

 Key: CASSANDRA-3014
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3014
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.0
Reporter: Hefeng Yuan
Priority: Minor

 Hi,
 We are seeing some AntiEntropy error in our production servers, since it's 
 hard to repro in other env, pasting the stack track here for some clue. 
 We're using a cluster of 2 data centers, 9 nodes, 6 for online traffic, 3 for 
 Brisk BI. Our RF is Cassandra:5, Brisk:1.
 Our Cassandra server version is 0.8.0. Data is written using Hector 0.7.0-20 
 and cassandra 0.7.2 library.
 Partitioner is random.
 Our nodetool repair is scheduled once per week.
 The exception stack is appended in the end.
 Any help is appreciated.
 Thanks,
 Hefeng
 ERROR [AntiEntropyStage:2] 2011-08-08 04:24:39,556 
 AbstractCassandraDaemon.java (line 113) Fatal exception in thread 
 Thread[AntiEntropyStage:2,5,main]
 java.lang.AssertionError
   at org.apache.cassandra.utils.MerkleTree.inc(MerkleTree.java:154)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:262)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284)
   at 
 

[Cassandra Wiki] Trivial Update of SNUNiki by SNUNiki

2013-02-12 Thread Apache Wiki
Dear Wiki user,

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

The SNUNiki page has been changed by SNUNiki:
http://wiki.apache.org/cassandra/SNUNiki

New page:
There is nothing to write about myself at all.BR
Great to be a member of apache.org.BR
I really wish I'm useful at allBR
BR
my web-site :: [[http://www.torontolimoservice1.com|Toronto airport limo 
service]]


[jira] [Updated] (CASSANDRA-4795) replication, compaction, compression? options are not validated

2013-02-12 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-4795:


Attachment: 0003-Adds-application_metadata-field-to-ks-metadata.txt
0002-Reallow-unexpected-strategy-options-for-thrift.txt
0001-Reallow-unexpected-strategy-options-for-thrift.txt

I'm a little bit confused about what you are trying to say. If you're saying 
we've broke stuff in a minor release, it's bad, we should revert the breakage, 
then I though I had made it pretty clear that I agree. But for 2.0 onwards, 
allowing to store random data in the replication strategy option *is* wrong: it 
doesn't even work with NTS (which will interpret the random data as a 
datacenter).

But anyway, less arguing more doing, I'm attaching patches that do the 
following:
* patch 1 re-allow unknown options in the replication strategy options on 
the thrift side (but not for CQL3 as I doubt there is any legacy CQL3 app using 
this since CQL3 is kind of new). It also allows startup if there was unknown 
options in the first place (that part was definitevely an oversight, the 
compaction strategy is clearly making sure to only log a warning in that case 
for instance).
* patch 2 does the same for the compaction strategy.
* patch 3 is my suggestion for an alternative to the problem I want to 
attach some tiny piece of metadata to a keyspace and creating a CF for that is 
overkill (for that patch the thrift file must be regen but I don't attach 
that). Could totally go into a separate ticket.

Those patches are against 1.2 but to be clear, my intent is to keep disallowing 
unknown options even for thrift in trunk.

 replication, compaction, compression? options are not validated
 ---

 Key: CASSANDRA-4795
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4795
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Brandon Williams
Assignee: Dave Brosius
Priority: Minor
 Fix For: 1.2.1

 Attachments: 0001-Reallow-unexpected-strategy-options-for-thrift.txt, 
 0002-Reallow-unexpected-strategy-options-for-thrift.txt, 
 0003-Adds-application_metadata-field-to-ks-metadata.txt, 
 4795.compaction_strategy.txt, 4795_compaction_strategy_v2.txt, 
 4795_compaction_strategy_v3.txt, 4795.replication_strategy.txt


 When creating a keyspace and specifying strategy options, you can pass any 
 k/v pair you like.

--
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: Make sure we catch all exception during bin protocol snappy initialization

2013-02-12 Thread slebresne
Updated Branches:
  refs/heads/cassandra-1.2 ce8b379c2 - 4b1fca7dc


Make sure we catch all exception during bin protocol snappy initialization


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

Branch: refs/heads/cassandra-1.2
Commit: 4b1fca7dcbc91c7429b5502614ef0b66c32a2116
Parents: ce8b379
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 12 13:59:41 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 12 13:59:56 2013 +0100

--
 .../cassandra/transport/FrameCompressor.java   |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4b1fca7d/src/java/org/apache/cassandra/transport/FrameCompressor.java
--
diff --git a/src/java/org/apache/cassandra/transport/FrameCompressor.java 
b/src/java/org/apache/cassandra/transport/FrameCompressor.java
index a22766f..3f96948 100644
--- a/src/java/org/apache/cassandra/transport/FrameCompressor.java
+++ b/src/java/org/apache/cassandra/transport/FrameCompressor.java
@@ -21,6 +21,7 @@ import java.io.IOException;
 
 import org.jboss.netty.buffer.ChannelBuffers;
 import org.xerial.snappy.Snappy;
+import org.xerial.snappy.SnappyError;
 
 public interface FrameCompressor
 {
@@ -41,10 +42,22 @@ public interface FrameCompressor
 {
 i = new SnappyCompressor();
 }
+catch (Exception e)
+{
+i = null;
+}
 catch (NoClassDefFoundError e)
 {
 i = null;
 }
+catch (SnappyError e)
+{
+i = null;
+}
+catch (UnsatisfiedLinkError e)
+{
+i = null;
+}
 instance = i;
 }
 



[1/2] git commit: Versions, news and changelog updates for 1.1.10 release

2013-02-12 Thread slebresne
Versions, news and changelog updates for 1.1.10 release


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

Branch: refs/heads/cassandra-1.2
Commit: 684994215120b2bac4e04f520420e105e21d07c9
Parents: 577cb2c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 12 08:37:43 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 12 08:37:43 2013 +0100

--
 CHANGES.txt  |3 +++
 NEWS.txt |8 
 build.xml|2 +-
 debian/changelog |6 ++
 4 files changed, 18 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0c76bd0..1ef799f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -6,6 +6,9 @@
  * add ConfigHelper support for Thrift frame and max message sizes 
(CASSANDRA-5188)
  * fix nodetool repair not fail on node down (CASSANDRA-5203)
  * always collect tombstone hints (CASSANDRA-5068)
+ * Fix thread growth on node removal (CASSANDRA-5175)
+ * Fix error when sourcing file in cqlsh (CASSANDRA-5235)
+ * Make Ec2Region's datacenter name configurable (CASSANDRA-5155)
 
 
 1.1.9

http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 04da469..b8954d4 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -8,6 +8,14 @@ upgrade, just in case you need to roll back to the previous 
version.
 (Cassandra version X + 1 will always be able to read data files created
 by version X, but the inverse is not necessarily the case.)
 
+1.1.10
+==
+
+Upgrading
+-
+- Nothing specific to this release, but please see the previous 
instructions
+  if you are not upgrading from 1.1.9.
+
 1.1.9
 =
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/build.xml
--
diff --git a/build.xml b/build.xml
index 1ca323d..6fa5172 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 property name=debuglevel value=source,lines,vars/
 
 !-- default version and SCM information --
-property name=base.version value=1.1.9/
+property name=base.version value=1.1.10/
 property name=scm.connection 
value=scm:git://git.apache.org/cassandra.git/
 property name=scm.developerConnection 
value=scm:git://git.apache.org/cassandra.git/
 property name=scm.url 
value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/

http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 445e3bf..46d1781 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (1.1.10) unstable; urgency=low
+
+  * New release
+
+ -- Sylvain Lebresne slebre...@apache.org  Tue, 12 Feb 2013 08:36:19 +0100
+
 cassandra (1.1.9) unstable; urgency=low
 
   * New release



[2/2] git commit: Merge branch 'cassandra-1.1' into cassandra-1.2

2013-02-12 Thread slebresne
Updated Branches:
  refs/heads/cassandra-1.2 4b1fca7dc - 858dfefe3


Merge branch 'cassandra-1.1' into cassandra-1.2

Conflicts:
NEWS.txt
build.xml
debian/changelog


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

Branch: refs/heads/cassandra-1.2
Commit: 858dfefe345be81caab038210c47750ad805b7d7
Parents: 4b1fca7 6849942
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 12 14:01:30 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 12 14:01:30 2013 +0100

--
 CHANGES.txt |3 +++
 build.xml   |2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/858dfefe/build.xml
--
diff --cc build.xml
index 772e8aa,6fa5172..421c8f3
--- a/build.xml
+++ b/build.xml
@@@ -25,7 -25,7 +25,7 @@@
  property name=debuglevel value=source,lines,vars/
  
  !-- default version and SCM information --
- property name=base.version value=1.2.1/
 -property name=base.version value=1.1.10/
++property name=base.version value=1.2.2/
  property name=scm.connection 
value=scm:git://git.apache.org/cassandra.git/
  property name=scm.developerConnection 
value=scm:git://git.apache.org/cassandra.git/
  property name=scm.url 
value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/



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

2013-02-12 Thread slebresne
Updated Branches:
  refs/heads/trunk 1d67b64f2 - e692c1b04


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

Branch: refs/heads/trunk
Commit: e692c1b04f3bcf4efa5150e9b47e9806ee894f85
Parents: 1d67b64 858dfef
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 12 14:02:04 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 12 14:02:04 2013 +0100

--
 CHANGES.txt|3 +++
 build.xml  |2 +-
 .../cassandra/transport/FrameCompressor.java   |   13 +
 3 files changed, 17 insertions(+), 1 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e692c1b0/build.xml
--



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

2013-02-12 Thread slebresne
Merge branch 'cassandra-1.1' into cassandra-1.2

Conflicts:
NEWS.txt
build.xml
debian/changelog


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

Branch: refs/heads/trunk
Commit: 858dfefe345be81caab038210c47750ad805b7d7
Parents: 4b1fca7 6849942
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 12 14:01:30 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 12 14:01:30 2013 +0100

--
 CHANGES.txt |3 +++
 build.xml   |2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/858dfefe/build.xml
--
diff --cc build.xml
index 772e8aa,6fa5172..421c8f3
--- a/build.xml
+++ b/build.xml
@@@ -25,7 -25,7 +25,7 @@@
  property name=debuglevel value=source,lines,vars/
  
  !-- default version and SCM information --
- property name=base.version value=1.2.1/
 -property name=base.version value=1.1.10/
++property name=base.version value=1.2.2/
  property name=scm.connection 
value=scm:git://git.apache.org/cassandra.git/
  property name=scm.developerConnection 
value=scm:git://git.apache.org/cassandra.git/
  property name=scm.url 
value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/



[2/4] git commit: Make sure we catch all exception during bin protocol snappy initialization

2013-02-12 Thread slebresne
Make sure we catch all exception during bin protocol snappy initialization


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

Branch: refs/heads/trunk
Commit: 4b1fca7dcbc91c7429b5502614ef0b66c32a2116
Parents: ce8b379
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 12 13:59:41 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 12 13:59:56 2013 +0100

--
 .../cassandra/transport/FrameCompressor.java   |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4b1fca7d/src/java/org/apache/cassandra/transport/FrameCompressor.java
--
diff --git a/src/java/org/apache/cassandra/transport/FrameCompressor.java 
b/src/java/org/apache/cassandra/transport/FrameCompressor.java
index a22766f..3f96948 100644
--- a/src/java/org/apache/cassandra/transport/FrameCompressor.java
+++ b/src/java/org/apache/cassandra/transport/FrameCompressor.java
@@ -21,6 +21,7 @@ import java.io.IOException;
 
 import org.jboss.netty.buffer.ChannelBuffers;
 import org.xerial.snappy.Snappy;
+import org.xerial.snappy.SnappyError;
 
 public interface FrameCompressor
 {
@@ -41,10 +42,22 @@ public interface FrameCompressor
 {
 i = new SnappyCompressor();
 }
+catch (Exception e)
+{
+i = null;
+}
 catch (NoClassDefFoundError e)
 {
 i = null;
 }
+catch (SnappyError e)
+{
+i = null;
+}
+catch (UnsatisfiedLinkError e)
+{
+i = null;
+}
 instance = i;
 }
 



[1/4] git commit: Versions, news and changelog updates for 1.1.10 release

2013-02-12 Thread slebresne
Versions, news and changelog updates for 1.1.10 release


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

Branch: refs/heads/trunk
Commit: 684994215120b2bac4e04f520420e105e21d07c9
Parents: 577cb2c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 12 08:37:43 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 12 08:37:43 2013 +0100

--
 CHANGES.txt  |3 +++
 NEWS.txt |8 
 build.xml|2 +-
 debian/changelog |6 ++
 4 files changed, 18 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0c76bd0..1ef799f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -6,6 +6,9 @@
  * add ConfigHelper support for Thrift frame and max message sizes 
(CASSANDRA-5188)
  * fix nodetool repair not fail on node down (CASSANDRA-5203)
  * always collect tombstone hints (CASSANDRA-5068)
+ * Fix thread growth on node removal (CASSANDRA-5175)
+ * Fix error when sourcing file in cqlsh (CASSANDRA-5235)
+ * Make Ec2Region's datacenter name configurable (CASSANDRA-5155)
 
 
 1.1.9

http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 04da469..b8954d4 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -8,6 +8,14 @@ upgrade, just in case you need to roll back to the previous 
version.
 (Cassandra version X + 1 will always be able to read data files created
 by version X, but the inverse is not necessarily the case.)
 
+1.1.10
+==
+
+Upgrading
+-
+- Nothing specific to this release, but please see the previous 
instructions
+  if you are not upgrading from 1.1.9.
+
 1.1.9
 =
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/build.xml
--
diff --git a/build.xml b/build.xml
index 1ca323d..6fa5172 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 property name=debuglevel value=source,lines,vars/
 
 !-- default version and SCM information --
-property name=base.version value=1.1.9/
+property name=base.version value=1.1.10/
 property name=scm.connection 
value=scm:git://git.apache.org/cassandra.git/
 property name=scm.developerConnection 
value=scm:git://git.apache.org/cassandra.git/
 property name=scm.url 
value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/

http://git-wip-us.apache.org/repos/asf/cassandra/blob/68499421/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 445e3bf..46d1781 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (1.1.10) unstable; urgency=low
+
+  * New release
+
+ -- Sylvain Lebresne slebre...@apache.org  Tue, 12 Feb 2013 08:36:19 +0100
+
 cassandra (1.1.9) unstable; urgency=low
 
   * New release



[jira] [Created] (CASSANDRA-5244) Compactions don't work while node is bootstrapping

2013-02-12 Thread Jouni Hartikainen (JIRA)
Jouni Hartikainen created CASSANDRA-5244:


 Summary: Compactions don't work while node is bootstrapping
 Key: CASSANDRA-5244
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5244
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.1
Reporter: Jouni Hartikainen
Priority: Critical


It seems that there is a race condition in StorageService that prevents 
compactions from completing while node is in a bootstrap state.

I have been able to reproduce this multiple times by throttling streaming 
throughput to extend the bootstrap time while simultaneously inserting data to 
the cluster.

The problems lies in the synchronization of initServer(int delay) and 
reportSeverity(double incr) methods as they both try to acquire the instance 
lock of StorageService through the use of synchronized keyword. As initServer 
does not return until the bootstrap has completed, all calls to reportSeverity 
will block until that. However, reportSeverity is called when starting 
compactions in CompactionInfo and thus all compactions block until bootstrap 
completes. 

This might severely degrade node's performance after bootstrap as it might have 
lots of compactions pending while simultaneously starting to serve reads.

I have been able to solve the issue by adding a separate lock for 
reportSeverity and removing its class level synchronization. This of course is 
not a valid approach if we must assume that any of Gossiper's 
IEndpointStateChangeSubscribers could potentially end up calling back to 
StorageService's synchronized methods. However, at least at the moment, that 
does not seem to be the case.

Maybe somebody with more experience about the codebase comes up with a better 
solution?

(This might affect DynamicEndpointSnitch as well, as it also calls to 
reportSeverity in its setSeverity method)

--
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-4795) replication, compaction, compression? options are not validated

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-4795:
---

bq. So in the case of Titan when they just want to save one 'last seen version' 
attribute, creating a separate column family or even having that per-cf doesn't 
make any sense but it's pretty convenient to keep it in the keypsace strategy 
options (without have any other alternatives) because it's not updated or even 
read that often.

No doubt everyone practicing this extremely awful hack has a perfectly good 
excuse. :)

But fundamentally creating a last_seen_versions table with cfname (ksname?) is 
simply not that onerous and is the Right Thing To Do.

bq. patch 3 is my suggestion for an alternative to the problem I want to 
attach some tiny piece of metadata to a keyspace and creating a CF for that is 
overkill

-1 from me, I get that change is painful for people who are abusing schema 
right now but we really shouldn't be encouraging this.

 replication, compaction, compression? options are not validated
 ---

 Key: CASSANDRA-4795
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4795
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Brandon Williams
Assignee: Dave Brosius
Priority: Minor
 Fix For: 1.2.1

 Attachments: 0001-Reallow-unexpected-strategy-options-for-thrift.txt, 
 0002-Reallow-unexpected-strategy-options-for-thrift.txt, 
 0003-Adds-application_metadata-field-to-ks-metadata.txt, 
 4795.compaction_strategy.txt, 4795_compaction_strategy_v2.txt, 
 4795_compaction_strategy_v3.txt, 4795.replication_strategy.txt


 When creating a keyspace and specifying strategy options, you can pass any 
 k/v pair you like.

--
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-5244) Compactions don't work while node is bootstrapping

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-5244:
--

Priority: Minor  (was: Critical)

Thanks for the detective work, Jouni.  I'll let Brandon comment on solutions; 
in the meantime, marking Minor since while inconvenient this does not 
compromise correctness.

 Compactions don't work while node is bootstrapping
 --

 Key: CASSANDRA-5244
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5244
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.1
Reporter: Jouni Hartikainen
Priority: Minor

 It seems that there is a race condition in StorageService that prevents 
 compactions from completing while node is in a bootstrap state.
 I have been able to reproduce this multiple times by throttling streaming 
 throughput to extend the bootstrap time while simultaneously inserting data 
 to the cluster.
 The problems lies in the synchronization of initServer(int delay) and 
 reportSeverity(double incr) methods as they both try to acquire the instance 
 lock of StorageService through the use of synchronized keyword. As initServer 
 does not return until the bootstrap has completed, all calls to 
 reportSeverity will block until that. However, reportSeverity is called when 
 starting compactions in CompactionInfo and thus all compactions block until 
 bootstrap completes. 
 This might severely degrade node's performance after bootstrap as it might 
 have lots of compactions pending while simultaneously starting to serve reads.
 I have been able to solve the issue by adding a separate lock for 
 reportSeverity and removing its class level synchronization. This of course 
 is not a valid approach if we must assume that any of Gossiper's 
 IEndpointStateChangeSubscribers could potentially end up calling back to 
 StorageService's synchronized methods. However, at least at the moment, that 
 does not seem to be the case.
 Maybe somebody with more experience about the codebase comes up with a better 
 solution?
 (This might affect DynamicEndpointSnitch as well, as it also calls to 
 reportSeverity in its setSeverity method)

--
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-5244) Compactions don't work while node is bootstrapping

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-5244:
--

  Component/s: Core
Fix Version/s: 1.2.2
   Labels: gossip  (was: )

 Compactions don't work while node is bootstrapping
 --

 Key: CASSANDRA-5244
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5244
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1
Reporter: Jouni Hartikainen
Priority: Minor
  Labels: gossip
 Fix For: 1.2.2


 It seems that there is a race condition in StorageService that prevents 
 compactions from completing while node is in a bootstrap state.
 I have been able to reproduce this multiple times by throttling streaming 
 throughput to extend the bootstrap time while simultaneously inserting data 
 to the cluster.
 The problems lies in the synchronization of initServer(int delay) and 
 reportSeverity(double incr) methods as they both try to acquire the instance 
 lock of StorageService through the use of synchronized keyword. As initServer 
 does not return until the bootstrap has completed, all calls to 
 reportSeverity will block until that. However, reportSeverity is called when 
 starting compactions in CompactionInfo and thus all compactions block until 
 bootstrap completes. 
 This might severely degrade node's performance after bootstrap as it might 
 have lots of compactions pending while simultaneously starting to serve reads.
 I have been able to solve the issue by adding a separate lock for 
 reportSeverity and removing its class level synchronization. This of course 
 is not a valid approach if we must assume that any of Gossiper's 
 IEndpointStateChangeSubscribers could potentially end up calling back to 
 StorageService's synchronized methods. However, at least at the moment, that 
 does not seem to be the case.
 Maybe somebody with more experience about the codebase comes up with a better 
 solution?
 (This might affect DynamicEndpointSnitch as well, as it also calls to 
 reportSeverity in its setSeverity method)

--
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-5245) AnitEntropy/MerkleTree Error

2013-02-12 Thread JIRA
David Röhr created CASSANDRA-5245:
-

 Summary: AnitEntropy/MerkleTree Error
 Key: CASSANDRA-5245
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5245
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1, 1.2.0
Reporter: David Röhr
Priority: Minor


We are seeing AntiEntropy errors when performing repair jobs in one of our 
Cassandra clusters. It seems to have started with 1.2. (maybe an issue with 
vnodes) The exceptions occur almost every time we try to do a repair on all 
column families in the cluster. Doing the same task on 1.1 does not trigger 
this.

6 nodes cluster (vnodes, murmur3, rf:3)
very low activity
running a nodetool repair -pr loop on the cluster nodes
nodetool hangs, and same big stacktrace in logs.

root 11025 0.0 0.0 106100 1436 pts/0 S+ Feb11 0:00 _ /bin/sh /usr/bin/nodetool 
-h HOST -p 7199 -pr repair KEYSPACE COLUMN_FAMILY

ERROR [AntiEntropyStage:3] 2013-02-11 17:08:12,630 CassandraDaemon.java (line 
133) Exception in thread Thread[AntiEntropyStage:3,5,main]
java.lang.AssertionError
at org.apache.cassandra.utils.MerkleTree.inc(MerkleTree.java:137)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:245)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:256)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 
org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
at 

[jira] [Commented] (CASSANDRA-5245) AnitEntropy/MerkleTree Error

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-5245:
---

That assertion is over 3 years old, so it's not as simple as 1.2 added a bogus 
assert.  (Which is not what you claimed, of course.)

 AnitEntropy/MerkleTree Error
 

 Key: CASSANDRA-5245
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5245
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0, 1.2.1
Reporter: David Röhr
Priority: Minor

 We are seeing AntiEntropy errors when performing repair jobs in one of our 
 Cassandra clusters. It seems to have started with 1.2. (maybe an issue with 
 vnodes) The exceptions occur almost every time we try to do a repair on all 
 column families in the cluster. Doing the same task on 1.1 does not trigger 
 this.
 6 nodes cluster (vnodes, murmur3, rf:3)
 very low activity
 running a nodetool repair -pr loop on the cluster nodes
 nodetool hangs, and same big stacktrace in logs.
 root 11025 0.0 0.0 106100 1436 pts/0 S+ Feb11 0:00 _ /bin/sh 
 /usr/bin/nodetool -h HOST -p 7199 -pr repair KEYSPACE COLUMN_FAMILY
 ERROR [AntiEntropyStage:3] 2013-02-11 17:08:12,630 CassandraDaemon.java (line 
 133) Exception in thread Thread[AntiEntropyStage:3,5,main]
 java.lang.AssertionError
   at org.apache.cassandra.utils.MerkleTree.inc(MerkleTree.java:137)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:245)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:256)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 

[jira] [Commented] (CASSANDRA-5245) AnitEntropy/MerkleTree Error

2013-02-12 Thread JIRA

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

David Röhr commented on CASSANDRA-5245:
---

What do you mean? That assertion is from my logs yesterday? Been able to repro 
it 3-4 times during the last couple of days.

The question was asked in the Cassandra User list to open a new bug or just 
edit the old one. Thats why I created a new one. 
(http://www.mail-archive.com/user@cassandra.apache.org/msg27686.html)

 AnitEntropy/MerkleTree Error
 

 Key: CASSANDRA-5245
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5245
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0, 1.2.1
Reporter: David Röhr
Priority: Minor

 We are seeing AntiEntropy errors when performing repair jobs in one of our 
 Cassandra clusters. It seems to have started with 1.2. (maybe an issue with 
 vnodes) The exceptions occur almost every time we try to do a repair on all 
 column families in the cluster. Doing the same task on 1.1 does not trigger 
 this.
 6 nodes cluster (vnodes, murmur3, rf:3)
 very low activity
 running a nodetool repair -pr loop on the cluster nodes
 nodetool hangs, and same big stacktrace in logs.
 root 11025 0.0 0.0 106100 1436 pts/0 S+ Feb11 0:00 _ /bin/sh 
 /usr/bin/nodetool -h HOST -p 7199 -pr repair KEYSPACE COLUMN_FAMILY
 ERROR [AntiEntropyStage:3] 2013-02-11 17:08:12,630 CassandraDaemon.java (line 
 133) Exception in thread Thread[AntiEntropyStage:3,5,main]
 java.lang.AssertionError
   at org.apache.cassandra.utils.MerkleTree.inc(MerkleTree.java:137)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:245)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:256)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 

[jira] [Comment Edited] (CASSANDRA-5245) AnitEntropy/MerkleTree Error

2013-02-12 Thread JIRA

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

David Röhr edited comment on CASSANDRA-5245 at 2/12/13 4:11 PM:


What do you mean? That assertion is from my logs yesterday? Been able to repro 
it 3-4 times during the last couple of days. I couldn't repro it on 1.1. (at 
least not so far)

The question was asked in the Cassandra User list to open a new bug or just 
edit the old one. Thats why I created a new one. 
(http://www.mail-archive.com/user@cassandra.apache.org/msg27686.html)

  was (Author: drohr):
What do you mean? That assertion is from my logs yesterday? Been able to 
repro it 3-4 times during the last couple of days.

The question was asked in the Cassandra User list to open a new bug or just 
edit the old one. Thats why I created a new one. 
(http://www.mail-archive.com/user@cassandra.apache.org/msg27686.html)
  
 AnitEntropy/MerkleTree Error
 

 Key: CASSANDRA-5245
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5245
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0, 1.2.1
Reporter: David Röhr
Priority: Minor

 We are seeing AntiEntropy errors when performing repair jobs in one of our 
 Cassandra clusters. It seems to have started with 1.2. (maybe an issue with 
 vnodes) The exceptions occur almost every time we try to do a repair on all 
 column families in the cluster. Doing the same task on 1.1 does not trigger 
 this.
 6 nodes cluster (vnodes, murmur3, rf:3)
 very low activity
 running a nodetool repair -pr loop on the cluster nodes
 nodetool hangs, and same big stacktrace in logs.
 root 11025 0.0 0.0 106100 1436 pts/0 S+ Feb11 0:00 _ /bin/sh 
 /usr/bin/nodetool -h HOST -p 7199 -pr repair KEYSPACE COLUMN_FAMILY
 ERROR [AntiEntropyStage:3] 2013-02-11 17:08:12,630 CassandraDaemon.java (line 
 133) Exception in thread Thread[AntiEntropyStage:3,5,main]
 java.lang.AssertionError
   at org.apache.cassandra.utils.MerkleTree.inc(MerkleTree.java:137)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:245)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:256)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 

[jira] [Comment Edited] (CASSANDRA-5245) AnitEntropy/MerkleTree Error

2013-02-12 Thread JIRA

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

David Röhr edited comment on CASSANDRA-5245 at 2/12/13 4:12 PM:


What do you mean? That assertion is from my logs yesterday? Been able to repro 
it 3-4 times during the last couple of days. I couldn't repro it on 1.1. (at 
least not so far). If it is a common assertion during repairs, then it should 
not be marked as closed.

The question was asked in the Cassandra User list to open a new bug or just 
edit the old one. Thats why I created a new one. 
(http://www.mail-archive.com/user@cassandra.apache.org/msg27686.html)

  was (Author: drohr):
What do you mean? That assertion is from my logs yesterday? Been able to 
repro it 3-4 times during the last couple of days. I couldn't repro it on 1.1. 
(at least not so far)

The question was asked in the Cassandra User list to open a new bug or just 
edit the old one. Thats why I created a new one. 
(http://www.mail-archive.com/user@cassandra.apache.org/msg27686.html)
  
 AnitEntropy/MerkleTree Error
 

 Key: CASSANDRA-5245
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5245
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0, 1.2.1
Reporter: David Röhr
Priority: Minor

 We are seeing AntiEntropy errors when performing repair jobs in one of our 
 Cassandra clusters. It seems to have started with 1.2. (maybe an issue with 
 vnodes) The exceptions occur almost every time we try to do a repair on all 
 column families in the cluster. Doing the same task on 1.1 does not trigger 
 this.
 6 nodes cluster (vnodes, murmur3, rf:3)
 very low activity
 running a nodetool repair -pr loop on the cluster nodes
 nodetool hangs, and same big stacktrace in logs.
 root 11025 0.0 0.0 106100 1436 pts/0 S+ Feb11 0:00 _ /bin/sh 
 /usr/bin/nodetool -h HOST -p 7199 -pr repair KEYSPACE COLUMN_FAMILY
 ERROR [AntiEntropyStage:3] 2013-02-11 17:08:12,630 CassandraDaemon.java (line 
 133) Exception in thread Thread[AntiEntropyStage:3,5,main]
 java.lang.AssertionError
   at org.apache.cassandra.utils.MerkleTree.inc(MerkleTree.java:137)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:245)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:256)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 

[Cassandra Wiki] Trivial Update of NydiaLand by NydiaLand

2013-02-12 Thread Apache Wiki
Dear Wiki user,

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

The NydiaLand page has been changed by NydiaLand:
http://wiki.apache.org/cassandra/NydiaLand

New page:
Hey guys !! I am CHIA PATRICK. I have a house in Oakland.BR
BR
This jan i will be 23. I go to night school at The Bountiful Institute in 
Gulfport-Biloxi. I am working as Farrier. One day i would want to do Hummels. 
My daddy name is Scott and he is a Political Scientist. My mummy is a 
Crafter.BR
BR
Also visit my page: [[http://www.justbeatsphone.com|beats dre]]


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

2013-02-12 Thread Ryan McGuire (JIRA)

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

Ryan McGuire updated CASSANDRA-4718:


Attachment: baq vs trunk.png

I ran a performance test comparing jonathan's baq branch with trunk and saw 
about a substantial increase in read performance.

 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
Priority: Minor
 Attachments: baq vs trunk.png, PerThreadQueue.java


 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 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-4718) More-efficient ExecutorService for improved throughput

2013-02-12 Thread Ryan McGuire (JIRA)

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

Ryan McGuire edited comment on CASSANDRA-4718 at 2/12/13 5:03 PM:
--

I ran a performance test comparing jonathan's baq branch with trunk and saw 
about a substantial increase in read performance. See http://goo.gl/ZeUS6 or 
see attached png.

  was (Author: enigmacurry):
I ran a performance test comparing jonathan's baq branch with trunk and saw 
about a substantial increase in read performance.
  
 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
Priority: Minor
 Attachments: baq vs trunk.png, PerThreadQueue.java


 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 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-4718) More-efficient ExecutorService for improved throughput

2013-02-12 Thread Ryan McGuire (JIRA)

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

Ryan McGuire edited comment on CASSANDRA-4718 at 2/12/13 5:04 PM:
--

I ran a performance test comparing jonathan's baq branch with trunk and saw a 
substantial increase in read performance. See http://goo.gl/ZeUS6 or see 
attached png.

  was (Author: enigmacurry):
I ran a performance test comparing jonathan's baq branch with trunk and saw 
about a substantial increase in read performance. See http://goo.gl/ZeUS6 or 
see attached png.
  
 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
Priority: Minor
 Attachments: baq vs trunk.png, PerThreadQueue.java


 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 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-4295) Implement caching of authorization results

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-4295:
---

v2 LGTM.

 Implement caching of authorization results
 --

 Key: CASSANDRA-4295
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Affects Versions: 1.1.0
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.2

 Attachments: 4295.txt, 4295-v2.txt, CASSANDRA-4295.patch


 1.2 will come with default IAuthority implementation that stores permissions 
 in Cassandra, and each permission check will involve at least 1 Cassandra 
 read. Some form of authorization result caching is very important for this 
 scenario.

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


[Cassandra Wiki] Trivial Update of MelisaChi by MelisaChi

2013-02-12 Thread Apache Wiki
Dear Wiki user,

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

The MelisaChi page has been changed by MelisaChi:
http://wiki.apache.org/cassandra/MelisaChi

New page:
Hey fellas !! The name is MARGORIE LIVINGSTON. This april i will be 24.BR
I study at The Lowest Preparatory built at Garden Grove. I want to become a 
Consultant. One day i would want to do Baseball. My father name is Bill and he 
is a Actor. My mother is a Shepherd.BR
BR
Here is my web blog - [[http://www.addiehandbags.com|gucci outlet online]]


git commit: Implement caching of authorization results

2013-02-12 Thread aleksey
Updated Branches:
  refs/heads/cassandra-1.2 858dfefe3 - d0f7e9e14


Implement caching of authorization results

Patch by Aleksey Yeschenko; reviewed by Jonathan Ellis for
CASSANDRA-4295


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

Branch: refs/heads/cassandra-1.2
Commit: d0f7e9e14a80ce29510672dd21cd04156b073514
Parents: 858dfef
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Feb 12 21:14:43 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Feb 12 21:14:43 2013 +0300

--
 CHANGES.txt|1 +
 conf/cassandra.yaml|5 ++
 .../apache/cassandra/auth/AuthenticatedUser.java   |   22 
 src/java/org/apache/cassandra/config/Config.java   |1 +
 .../cassandra/config/DatabaseDescriptor.java   |5 ++
 .../cassandra/cql3/statements/BatchStatement.java  |   17 +--
 .../org/apache/cassandra/service/ClientState.java  |   42 ++-
 .../apache/cassandra/thrift/CassandraServer.java   |8 +---
 8 files changed, 77 insertions(+), 24 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0f7e9e1/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f176742..466dca6 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -15,6 +15,7 @@
  * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366)
  * CQL3 refactor to allow conversion function (CASSANDRA-5226)
  * Fix drop of sstables in some circumstance (CASSANDRA-5232)
+ * Implement caching of authorization results (CASSANDRA-4295)
 
 
 1.2.1

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0f7e9e1/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 14f4e96..f027c15 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -60,6 +60,11 @@ authenticator: 
org.apache.cassandra.auth.AllowAllAuthenticator
 # authorization backend, implementing IAuthorizer; used to limit 
access/provide permissions
 authorizer: org.apache.cassandra.auth.AllowAllAuthorizer
 
+# Validity period for permissions cache (fetching permissions can be an
+# expensive operation depending on the authorizer). Defaults to 2000,
+# set to 0 to disable. Will be disabled automatically for AllowAllAuthorizer.
+permissions_validity_in_ms: 2000
+
 # The partitioner is responsible for distributing rows (by key) across
 # nodes in the cluster.  Any IPartitioner may be used, including your
 # own as long as it is on the classpath.  Out of the box, Cassandra

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0f7e9e1/src/java/org/apache/cassandra/auth/AuthenticatedUser.java
--
diff --git a/src/java/org/apache/cassandra/auth/AuthenticatedUser.java 
b/src/java/org/apache/cassandra/auth/AuthenticatedUser.java
index cf208b8..f834878 100644
--- a/src/java/org/apache/cassandra/auth/AuthenticatedUser.java
+++ b/src/java/org/apache/cassandra/auth/AuthenticatedUser.java
@@ -17,6 +17,8 @@
  */
 package org.apache.cassandra.auth;
 
+import com.google.common.base.Objects;
+
 /**
  * Returned from IAuthenticator#authenticate(), represents an authenticated 
user everywhere internally.
  */
@@ -61,4 +63,24 @@ public class AuthenticatedUser
 {
 return String.format(#User %s, name);
 }
+
+@Override
+public boolean equals(Object o)
+{
+if (this == o)
+return true;
+
+if (!(o instanceof AuthenticatedUser))
+return false;
+
+AuthenticatedUser u = (AuthenticatedUser) o;
+
+return Objects.equal(this.name, u.name);
+}
+
+@Override
+public int hashCode()
+{
+return Objects.hashCode(name);
+}
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0f7e9e1/src/java/org/apache/cassandra/config/Config.java
--
diff --git a/src/java/org/apache/cassandra/config/Config.java 
b/src/java/org/apache/cassandra/config/Config.java
index d8a8afd..02324ee 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -33,6 +33,7 @@ public class Config
 public String authenticator;
 public String authority; // for backwards compatibility - will log a 
warning.
 public String authorizer;
+public int permissions_validity_in_ms = 2000;
 
 /* Hashing strategy Random or OPHF */
 public String partitioner;


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

2013-02-12 Thread aleksey
Updated Branches:
  refs/heads/trunk e692c1b04 - f425c9251


Merge branch 'cassandra-1.2' into trunk

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

Branch: refs/heads/trunk
Commit: f425c92513c117e8347b8118a0e319ef72c71a62
Parents: e692c1b d0f7e9e
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Feb 12 21:19:18 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Feb 12 21:19:18 2013 +0300

--
 CHANGES.txt|1 +
 conf/cassandra.yaml|5 ++
 .../apache/cassandra/auth/AuthenticatedUser.java   |   22 
 src/java/org/apache/cassandra/config/Config.java   |1 +
 .../cassandra/config/DatabaseDescriptor.java   |5 ++
 .../cassandra/cql3/statements/BatchStatement.java  |   17 +--
 .../org/apache/cassandra/service/ClientState.java  |   42 ++-
 .../apache/cassandra/thrift/CassandraServer.java   |8 +---
 8 files changed, 77 insertions(+), 24 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f425c925/CHANGES.txt
--
diff --cc CHANGES.txt
index cc5e0d8,466dca6..a850c6b
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -23,7 -15,7 +23,8 @@@
   * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366)
   * CQL3 refactor to allow conversion function (CASSANDRA-5226)
   * Fix drop of sstables in some circumstance (CASSANDRA-5232)
 + * Add support for LZ4 compression (CASSANDRA-5038)
+  * Implement caching of authorization results (CASSANDRA-4295)
  
  
  1.2.1

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f425c925/conf/cassandra.yaml
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f425c925/src/java/org/apache/cassandra/config/Config.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f425c925/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f425c925/src/java/org/apache/cassandra/thrift/CassandraServer.java
--



[1/2] git commit: Implement caching of authorization results

2013-02-12 Thread aleksey
Implement caching of authorization results

Patch by Aleksey Yeschenko; reviewed by Jonathan Ellis for
CASSANDRA-4295


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

Branch: refs/heads/trunk
Commit: d0f7e9e14a80ce29510672dd21cd04156b073514
Parents: 858dfef
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Feb 12 21:14:43 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Feb 12 21:14:43 2013 +0300

--
 CHANGES.txt|1 +
 conf/cassandra.yaml|5 ++
 .../apache/cassandra/auth/AuthenticatedUser.java   |   22 
 src/java/org/apache/cassandra/config/Config.java   |1 +
 .../cassandra/config/DatabaseDescriptor.java   |5 ++
 .../cassandra/cql3/statements/BatchStatement.java  |   17 +--
 .../org/apache/cassandra/service/ClientState.java  |   42 ++-
 .../apache/cassandra/thrift/CassandraServer.java   |8 +---
 8 files changed, 77 insertions(+), 24 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0f7e9e1/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f176742..466dca6 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -15,6 +15,7 @@
  * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366)
  * CQL3 refactor to allow conversion function (CASSANDRA-5226)
  * Fix drop of sstables in some circumstance (CASSANDRA-5232)
+ * Implement caching of authorization results (CASSANDRA-4295)
 
 
 1.2.1

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0f7e9e1/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 14f4e96..f027c15 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -60,6 +60,11 @@ authenticator: 
org.apache.cassandra.auth.AllowAllAuthenticator
 # authorization backend, implementing IAuthorizer; used to limit 
access/provide permissions
 authorizer: org.apache.cassandra.auth.AllowAllAuthorizer
 
+# Validity period for permissions cache (fetching permissions can be an
+# expensive operation depending on the authorizer). Defaults to 2000,
+# set to 0 to disable. Will be disabled automatically for AllowAllAuthorizer.
+permissions_validity_in_ms: 2000
+
 # The partitioner is responsible for distributing rows (by key) across
 # nodes in the cluster.  Any IPartitioner may be used, including your
 # own as long as it is on the classpath.  Out of the box, Cassandra

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0f7e9e1/src/java/org/apache/cassandra/auth/AuthenticatedUser.java
--
diff --git a/src/java/org/apache/cassandra/auth/AuthenticatedUser.java 
b/src/java/org/apache/cassandra/auth/AuthenticatedUser.java
index cf208b8..f834878 100644
--- a/src/java/org/apache/cassandra/auth/AuthenticatedUser.java
+++ b/src/java/org/apache/cassandra/auth/AuthenticatedUser.java
@@ -17,6 +17,8 @@
  */
 package org.apache.cassandra.auth;
 
+import com.google.common.base.Objects;
+
 /**
  * Returned from IAuthenticator#authenticate(), represents an authenticated 
user everywhere internally.
  */
@@ -61,4 +63,24 @@ public class AuthenticatedUser
 {
 return String.format(#User %s, name);
 }
+
+@Override
+public boolean equals(Object o)
+{
+if (this == o)
+return true;
+
+if (!(o instanceof AuthenticatedUser))
+return false;
+
+AuthenticatedUser u = (AuthenticatedUser) o;
+
+return Objects.equal(this.name, u.name);
+}
+
+@Override
+public int hashCode()
+{
+return Objects.hashCode(name);
+}
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0f7e9e1/src/java/org/apache/cassandra/config/Config.java
--
diff --git a/src/java/org/apache/cassandra/config/Config.java 
b/src/java/org/apache/cassandra/config/Config.java
index d8a8afd..02324ee 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -33,6 +33,7 @@ public class Config
 public String authenticator;
 public String authority; // for backwards compatibility - will log a 
warning.
 public String authorizer;
+public int permissions_validity_in_ms = 2000;
 
 /* Hashing strategy Random or OPHF */
 public String partitioner;


[1/3] git commit: Add support for LZ4 compression patch by Adrien Grand; reviewed by tjake for CASSANDRA-5038

2013-02-12 Thread jbellis
Add support for LZ4 compression
patch by Adrien Grand; reviewed by tjake for CASSANDRA-5038


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

Branch: refs/heads/cassandra-1.2
Commit: aa7c7d9cd74a8626cfac95c01a9f6ff9801bf45f
Parents: d0f7e9e
Author: Jonathan Ellis jbel...@apache.org
Authored: Sun Feb 10 23:58:42 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Feb 12 12:25:32 2013 -0600

--
 CHANGES.txt|1 +
 NOTICE.txt |5 +
 build.xml  |2 +
 lib/licenses/lz4-1.1.0.txt |  235 +++
 lib/lz4-1.1.0.jar  |  Bin 0 - 134748 bytes
 .../cassandra/io/compress/LZ4Compressor.java   |  104 +++
 .../cassandra/io/compress/LZ4CompressorTest.java   |   84 +
 7 files changed, 431 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/aa7c7d9c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 466dca6..0621c79 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -16,6 +16,7 @@
  * CQL3 refactor to allow conversion function (CASSANDRA-5226)
  * Fix drop of sstables in some circumstance (CASSANDRA-5232)
  * Implement caching of authorization results (CASSANDRA-4295)
+ * Add support for LZ4 compression (CASSANDRA-5038)
 
 
 1.2.1

http://git-wip-us.apache.org/repos/asf/cassandra/blob/aa7c7d9c/NOTICE.txt
--
diff --git a/NOTICE.txt b/NOTICE.txt
index 71f38fe..9826990 100644
--- a/NOTICE.txt
+++ b/NOTICE.txt
@@ -44,3 +44,8 @@ Written by Nathan G. Bronson et al.
 CQL Native transport uses Netty
 (https://netty.io/)
 Copyright (C) 2011 The Netty Project
+
+LZ4 compression support provided by lz4-java 
(http://github.com/jpountz/lz4-java)
+Written by Adrien Grand.
+Contains bindings to the C LZ4 implementation (http://code.google.com/p/lz4/)
+Copyright (C) 2011-2012, Yann Collet.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/aa7c7d9c/build.xml
--
diff --git a/build.xml b/build.xml
index 421c8f3..ea0bbd7 100644
--- a/build.xml
+++ b/build.xml
@@ -329,6 +329,7 @@
 scm connection=${scm.connection} 
developerConnection=${scm.developerConnection} url=${scm.url}/
 dependencyManagement
   dependency groupId=org.xerial.snappy artifactId=snappy-java 
version=1.0.4.1/
+  dependency groupId=net.jpountz.lz4 artifactId=lz4 
version=1.1.0/
   dependency groupId=com.ning artifactId=compress-lzf 
version=0.8.4/
   dependency groupId=com.google.guava artifactId=guava 
version=12.0/
   dependency groupId=commons-cli artifactId=commons-cli 
version=1.1/
@@ -443,6 +444,7 @@
 version=${version}/
 scm connection=${scm.connection} 
developerConnection=${scm.developerConnection} url=${scm.url}/
 dependency groupId=org.xerial.snappy artifactId=snappy-java/
+dependency groupId=net.jpountz.lz4 artifactId=lz4/
 dependency groupId=com.ning artifactId=compress-lzf/
 dependency groupId=com.google.guava artifactId=guava/
 dependency groupId=commons-cli artifactId=commons-cli/

http://git-wip-us.apache.org/repos/asf/cassandra/blob/aa7c7d9c/lib/licenses/lz4-1.1.0.txt
--
diff --git a/lib/licenses/lz4-1.1.0.txt b/lib/licenses/lz4-1.1.0.txt
new file mode 100644
index 000..7f3ef36
--- /dev/null
+++ b/lib/licenses/lz4-1.1.0.txt
@@ -0,0 +1,235 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  License shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  Licensor shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  Legal Entity shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  control means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership 

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

2013-02-12 Thread jbellis
Updated Branches:
  refs/heads/cassandra-1.2 d0f7e9e14 - aa7c7d9cd
  refs/heads/trunk f425c9251 - 06d9bda83


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

Branch: refs/heads/trunk
Commit: 06d9bda8322e4d4d267668f3bf8dded109e2b473
Parents: f425c92 aa7c7d9
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Feb 12 12:25:41 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Feb 12 12:25:41 2013 -0600

--
 CHANGES.txt |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/06d9bda8/CHANGES.txt
--
diff --cc CHANGES.txt
index a850c6b,0621c79..fe6d19e
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -23,8 -15,8 +23,9 @@@
   * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366)
   * CQL3 refactor to allow conversion function (CASSANDRA-5226)
   * Fix drop of sstables in some circumstance (CASSANDRA-5232)
 + * Add support for LZ4 compression (CASSANDRA-5038)
   * Implement caching of authorization results (CASSANDRA-4295)
+  * Add support for LZ4 compression (CASSANDRA-5038)
  
  
  1.2.1



[2/3] git commit: Add support for LZ4 compression patch by Adrien Grand; reviewed by tjake for CASSANDRA-5038

2013-02-12 Thread jbellis
Add support for LZ4 compression
patch by Adrien Grand; reviewed by tjake for CASSANDRA-5038


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

Branch: refs/heads/trunk
Commit: aa7c7d9cd74a8626cfac95c01a9f6ff9801bf45f
Parents: d0f7e9e
Author: Jonathan Ellis jbel...@apache.org
Authored: Sun Feb 10 23:58:42 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Feb 12 12:25:32 2013 -0600

--
 CHANGES.txt|1 +
 NOTICE.txt |5 +
 build.xml  |2 +
 lib/licenses/lz4-1.1.0.txt |  235 +++
 lib/lz4-1.1.0.jar  |  Bin 0 - 134748 bytes
 .../cassandra/io/compress/LZ4Compressor.java   |  104 +++
 .../cassandra/io/compress/LZ4CompressorTest.java   |   84 +
 7 files changed, 431 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/aa7c7d9c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 466dca6..0621c79 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -16,6 +16,7 @@
  * CQL3 refactor to allow conversion function (CASSANDRA-5226)
  * Fix drop of sstables in some circumstance (CASSANDRA-5232)
  * Implement caching of authorization results (CASSANDRA-4295)
+ * Add support for LZ4 compression (CASSANDRA-5038)
 
 
 1.2.1

http://git-wip-us.apache.org/repos/asf/cassandra/blob/aa7c7d9c/NOTICE.txt
--
diff --git a/NOTICE.txt b/NOTICE.txt
index 71f38fe..9826990 100644
--- a/NOTICE.txt
+++ b/NOTICE.txt
@@ -44,3 +44,8 @@ Written by Nathan G. Bronson et al.
 CQL Native transport uses Netty
 (https://netty.io/)
 Copyright (C) 2011 The Netty Project
+
+LZ4 compression support provided by lz4-java 
(http://github.com/jpountz/lz4-java)
+Written by Adrien Grand.
+Contains bindings to the C LZ4 implementation (http://code.google.com/p/lz4/)
+Copyright (C) 2011-2012, Yann Collet.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/aa7c7d9c/build.xml
--
diff --git a/build.xml b/build.xml
index 421c8f3..ea0bbd7 100644
--- a/build.xml
+++ b/build.xml
@@ -329,6 +329,7 @@
 scm connection=${scm.connection} 
developerConnection=${scm.developerConnection} url=${scm.url}/
 dependencyManagement
   dependency groupId=org.xerial.snappy artifactId=snappy-java 
version=1.0.4.1/
+  dependency groupId=net.jpountz.lz4 artifactId=lz4 
version=1.1.0/
   dependency groupId=com.ning artifactId=compress-lzf 
version=0.8.4/
   dependency groupId=com.google.guava artifactId=guava 
version=12.0/
   dependency groupId=commons-cli artifactId=commons-cli 
version=1.1/
@@ -443,6 +444,7 @@
 version=${version}/
 scm connection=${scm.connection} 
developerConnection=${scm.developerConnection} url=${scm.url}/
 dependency groupId=org.xerial.snappy artifactId=snappy-java/
+dependency groupId=net.jpountz.lz4 artifactId=lz4/
 dependency groupId=com.ning artifactId=compress-lzf/
 dependency groupId=com.google.guava artifactId=guava/
 dependency groupId=commons-cli artifactId=commons-cli/

http://git-wip-us.apache.org/repos/asf/cassandra/blob/aa7c7d9c/lib/licenses/lz4-1.1.0.txt
--
diff --git a/lib/licenses/lz4-1.1.0.txt b/lib/licenses/lz4-1.1.0.txt
new file mode 100644
index 000..7f3ef36
--- /dev/null
+++ b/lib/licenses/lz4-1.1.0.txt
@@ -0,0 +1,235 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  License shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  Licensor shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  Legal Entity shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  control means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty 

git commit: Remove duplicate 5038 from CHANGES.txt

2013-02-12 Thread aleksey
Updated Branches:
  refs/heads/trunk 06d9bda83 - dd4d798dc


Remove duplicate 5038 from CHANGES.txt


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

Branch: refs/heads/trunk
Commit: dd4d798dcd6a65c2eba697f87f8889871c262230
Parents: 06d9bda
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Feb 12 21:31:11 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Feb 12 21:31:11 2013 +0300

--
 CHANGES.txt |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/dd4d798d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fe6d19e..fa5e46e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -6,6 +6,7 @@
  * replace supercolumns internally by composites (CASSANDRA-3237, 5123)
  * upgrade thrift to 0.9.0 (CASSANDRA-3719)
 
+
 1.2.2
  * avoid no-op caching of byte[] on commitlog append (CASSANDRA-5199)
  * more robust solution to incomplete compactions + counters (CASSANDRA-5151)
@@ -23,7 +24,6 @@
  * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366)
  * CQL3 refactor to allow conversion function (CASSANDRA-5226)
  * Fix drop of sstables in some circumstance (CASSANDRA-5232)
- * Add support for LZ4 compression (CASSANDRA-5038)
  * Implement caching of authorization results (CASSANDRA-4295)
  * Add support for LZ4 compression (CASSANDRA-5038)
 



[jira] [Commented] (CASSANDRA-5149) Respect slice count even if column expire mid-request

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-5149:
---

What if we forced ExpiringColumn to either Column or DeletedColumn on the reply?

 Respect slice count even if column expire mid-request
 -

 Key: CASSANDRA-5149
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.7.0
Reporter: Sylvain Lebresne
 Fix For: 2.0


 This is a follow-up of CASSANDRA-5099.
 If a column expire just while a slice query is performed, it is possible for 
 replicas to count said column as live but to have the coordinator seeing it 
 as dead when building the final result. The effect that the query might 
 return strictly less columns that the requested slice count even though there 
 is some live columns matching the slice predicate but not returned in the 
 result.

--
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-5225) Missing columns, errors when requesting specific columns from wide rows

2013-02-12 Thread Elden Bishop (JIRA)

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

Elden Bishop commented on CASSANDRA-5225:
-

This patch also fixes CASSANDRA-5210. I'll mark that one as a dupe.

 Missing columns, errors when requesting specific columns from wide rows
 ---

 Key: CASSANDRA-5225
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5225
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1
Reporter: Tyler Hobbs
Priority: Critical
 Fix For: 1.2.2

 Attachments: 5225.txt, pycassa-repro.py


 With Cassandra 1.2.1 (and probably 1.2.0), I'm seeing some problems with 
 Thrift queries that request a set of specific column names when the row is 
 very wide.
 To reproduce, I'm inserting 10 million columns into a single row and then 
 randomly requesting three columns by name in a loop.  It's common for only 
 one or two of the three columns to be returned.  I'm also seeing stack traces 
 like the following in the Cassandra log:
 {noformat}
 ERROR 13:12:01,017 Exception in thread Thread[ReadStage:76,5,main]
 java.lang.RuntimeException: 
 org.apache.cassandra.io.sstable.CorruptSSTableException: 
 org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid 
 column name length 0 
 (/var/lib/cassandra/data/Keyspace1/CF1/Keyspace1-CF1-ib-5-Data.db, 14035168 
 bytes remaining)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1576)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: 
 org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid 
 column name length 0 
 (/var/lib/cassandra/data/Keyspace1/CF1/Keyspace1-CF1-ib-5-Data.db, 14035168 
 bytes remaining)
   at 
 org.apache.cassandra.db.columniterator.SSTableNamesIterator.init(SSTableNamesIterator.java:69)
   at 
 org.apache.cassandra.db.filter.NamesQueryFilter.getSSTableColumnIterator(NamesQueryFilter.java:81)
   at 
 org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:68)
   at 
 org.apache.cassandra.db.CollationController.collectTimeOrderedData(CollationController.java:133)
   at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:65)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1358)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1215)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1127)
   at org.apache.cassandra.db.Table.getRow(Table.java:355)
   at 
 org.apache.cassandra.db.SliceByNamesReadCommand.getRow(SliceByNamesReadCommand.java:64)
   at 
 org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1052)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1572)
   ... 3 more
 {noformat}
 This doesn't seem to happen when the row is smaller, so it might have 
 something to do with incremental large row compaction.

--
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-5210) DB is randomly and undetectably corrupted during high traffic column family flushes

2013-02-12 Thread Elden Bishop (JIRA)

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

Elden Bishop resolved CASSANDRA-5210.
-

Resolution: Duplicate

The patch submitted for CASSANDRA-5225 fixes this issue.

 DB is randomly and undetectably corrupted during high traffic column family 
 flushes 
 

 Key: CASSANDRA-5210
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5210
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.8.8, 
 0.8.9, 0.8.10, 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.1.7, 1.1.8, 
 1.1.9, 1.2.0, 1.2.1
 Environment: Cassandra 0.8+, OS/X, java version 1.6.0_37 
Reporter: Elden Bishop

 Writes during high traffic column family flushes corrupt the DB and make 
 slice queries return incorrect data.
 Any multi-column write on any version of Cassandra can put the DB in a state 
 where some columns cannot be read alongside other columns.
 eg.
 {{
 // *** for any NON-NULL column (eg. col_a=AAA)
 cqlsh SELECT 'col_a' FROM test WHERE KEY='row_a';
returns: 'AAA'
 // *** it can disappear when queried alongside another column
 cqlsh SELECT 'col_a', 'col_b' FROM test WHERE KEY='row_a';
returns:  null,   'BBB' // *** col_a is MISSING
 // *** but it depends on the other columns
 cqlsh SELECT 'col_a', 'col_b', 'col_c' FROM test WHERE KEY='row_a';
returns: 'AAA',   'BBB',   'CCC' // *** col_a is BACK
 }}
 Once in this state the database is corrupt and essentially returning random 
 data depending on what columns you query. Single column queries always return 
 correct results so there is no way to verify the data. No errors are logged 
 during corruption and it is impossible to detect without querying all 
 combinations of all columns.
 To reproduce:
 1. Unzip a distribution of Cassandra and create a test.test column family.
 2. In a loop alternate between updating either row 'a' or a random row.
Write a random value to four random columns (out of 1). Keep track
of all columns set in row 'a'.
 3. Each pass through the loop query four random columns (out of 1) from 
 row 'a'. If a column that is known to be set is null, print out the columns 
 that were requested during the query.
 4. The DB is now corrupt and will return the column if queried by itself but 
 will return null if queried alongside the columns that triggered the error. 
 This is a permanent condition.
 Observations: This bug only manifests directly after a high traffic column 
 family flush occurs in the log. This is a correlation based on simply 
 watching the log. There are no errors or warnings of any kind.
 Workaround: Any multi-column read is potentially invalid and corruption is 
 virtually undetectable. The only workaround is never writing or reading more 
 than a single column in a query.
 I have a simple groovy script that can trigger the error. I have verified the 
 behavior on Cassandra versions as old as 0.8.1

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


[Cassandra Wiki] Trivial Update of KellyE90 by KellyE90

2013-02-12 Thread Apache Wiki
Dear Wiki user,

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

The KellyE90 page has been changed by KellyE90:
http://wiki.apache.org/cassandra/KellyE90

New page:
Hello !! I am ESSIE JUSTICE. I reside in Newark.BR
Soon i will turn 21. I might join The Cloudy Boarding School which has a branch 
in Punta Gorda. I am working as Educationalist. One day i would want to do 
Engraving. My papa name is  Ross and he is a Gladiator. My mom is a 
Psychologist.BR
BR
Here is my blog [[http://www.justbeatsphone.com|cheap monster beats]]


[jira] [Updated] (CASSANDRA-5211) Migrating Clusters with gossip tables that have old dead nodes causes NPE, inability to join cluster

2013-02-12 Thread Brandon Williams (JIRA)

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

Brandon Williams updated CASSANDRA-5211:


Reviewer: slebresne

 Migrating Clusters with gossip tables that have old dead nodes causes NPE, 
 inability to join cluster
 

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

 Attachments: 5211.txt


 I had done a removetoken on this cluster when it was 1.1.x, and it had a 
 ghost entry for the removed node still in the stored ring data. When the 
 nodes loaded the table up after conversion to 1.2 and attempting to migrate 
 to VNodes, I got the following traceback:
 ERROR [WRITE-/10.0.0.0] 2013-01-31 18:35:44,788 CassandraDaemon.java (line 
 133) Exception in thread Thread[WRITE-/10.0.0.0,5,main]
 java.lang.NullPointerException
   at 
 org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
   at 
 org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:73)
   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:93)
   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:32)
   at 
 org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:96)
   at 
 org.apache.cassandra.db.SystemTable.loadDcRackInfo(SystemTable.java:402)
   at 
 org.apache.cassandra.locator.Ec2Snitch.getDatacenter(Ec2Snitch.java:117)
   at 
 org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:127)
   at 
 org.apache.cassandra.net.OutboundTcpConnection.isLocalDC(OutboundTcpConnection.java:74)
   at 
 org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:270)
   at 
 org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:142)
 This is because these ghost nodes had a NULL tokens list in the system/peers 
 table. A workaround was to delete the offending row in the system/peers table 
 and restart the node.

--
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-5244) Compactions don't work while node is bootstrapping

2013-02-12 Thread Brandon Williams (JIRA)

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

Brandon Williams reassigned CASSANDRA-5244:
---

Assignee: Brandon Williams

 Compactions don't work while node is bootstrapping
 --

 Key: CASSANDRA-5244
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5244
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1
Reporter: Jouni Hartikainen
Assignee: Brandon Williams
Priority: Minor
  Labels: gossip
 Fix For: 1.2.2


 It seems that there is a race condition in StorageService that prevents 
 compactions from completing while node is in a bootstrap state.
 I have been able to reproduce this multiple times by throttling streaming 
 throughput to extend the bootstrap time while simultaneously inserting data 
 to the cluster.
 The problems lies in the synchronization of initServer(int delay) and 
 reportSeverity(double incr) methods as they both try to acquire the instance 
 lock of StorageService through the use of synchronized keyword. As initServer 
 does not return until the bootstrap has completed, all calls to 
 reportSeverity will block until that. However, reportSeverity is called when 
 starting compactions in CompactionInfo and thus all compactions block until 
 bootstrap completes. 
 This might severely degrade node's performance after bootstrap as it might 
 have lots of compactions pending while simultaneously starting to serve reads.
 I have been able to solve the issue by adding a separate lock for 
 reportSeverity and removing its class level synchronization. This of course 
 is not a valid approach if we must assume that any of Gossiper's 
 IEndpointStateChangeSubscribers could potentially end up calling back to 
 StorageService's synchronized methods. However, at least at the moment, that 
 does not seem to be the case.
 Maybe somebody with more experience about the codebase comes up with a better 
 solution?
 (This might affect DynamicEndpointSnitch as well, as it also calls to 
 reportSeverity in its setSeverity method)

--
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-5244) Compactions don't work while node is bootstrapping

2013-02-12 Thread Brandon Williams (JIRA)

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

Brandon Williams updated CASSANDRA-5244:


Affects Version/s: (was: 1.2.1)
   1.2.0 beta 1

 Compactions don't work while node is bootstrapping
 --

 Key: CASSANDRA-5244
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5244
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Jouni Hartikainen
Assignee: Brandon Williams
Priority: Minor
  Labels: gossip
 Fix For: 1.2.2


 It seems that there is a race condition in StorageService that prevents 
 compactions from completing while node is in a bootstrap state.
 I have been able to reproduce this multiple times by throttling streaming 
 throughput to extend the bootstrap time while simultaneously inserting data 
 to the cluster.
 The problems lies in the synchronization of initServer(int delay) and 
 reportSeverity(double incr) methods as they both try to acquire the instance 
 lock of StorageService through the use of synchronized keyword. As initServer 
 does not return until the bootstrap has completed, all calls to 
 reportSeverity will block until that. However, reportSeverity is called when 
 starting compactions in CompactionInfo and thus all compactions block until 
 bootstrap completes. 
 This might severely degrade node's performance after bootstrap as it might 
 have lots of compactions pending while simultaneously starting to serve reads.
 I have been able to solve the issue by adding a separate lock for 
 reportSeverity and removing its class level synchronization. This of course 
 is not a valid approach if we must assume that any of Gossiper's 
 IEndpointStateChangeSubscribers could potentially end up calling back to 
 StorageService's synchronized methods. However, at least at the moment, that 
 does not seem to be the case.
 Maybe somebody with more experience about the codebase comes up with a better 
 solution?
 (This might affect DynamicEndpointSnitch as well, as it also calls to 
 reportSeverity in its setSeverity method)

--
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-5243) cassandra-stress aggregate statistics

2013-02-12 Thread Brandon Williams (JIRA)

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

Brandon Williams updated CASSANDRA-5243:


Reviewer: brandon.williams
Assignee: Ryan McGuire

 cassandra-stress aggregate statistics
 -

 Key: CASSANDRA-5243
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5243
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Ryan McGuire
Assignee: Ryan McGuire
Priority: Minor
 Attachments: trunk-5243.txt


 cassandra-stress should output some aggregated statistics for the data that 
 it outputs. In testing the performance of a Cassandra cluster it's useful to 
 look at the performance by establishing what the average read/write rate is 
 during the middle 80% of a stress job (the first and last 10% being outliers 
 as the cluster is starting and stopping a big operation.)
 I've implemented this to add these stats to the end of the cassandra-stress 
 output. It also adds a command line option to turn it off if it's not desired.
 My branch here: 
 https://github.com/EnigmaCurry/cassandra/commit/157993d087015b17267e613a458d5bc8bd36a888

--
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-2698) Instrument repair to be able to assess it's efficiency (precision)

2013-02-12 Thread Brandon Williams (JIRA)

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

Brandon Williams updated CASSANDRA-2698:


Reviewer: yukim

 Instrument repair to be able to assess it's efficiency (precision)
 --

 Key: CASSANDRA-2698
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2698
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Priority: Minor
  Labels: lhf
 Attachments: nodetool_repair_and_cfhistogram.tar.gz, patch_2698_v1.txt


 Some reports indicate that repair sometime transfer huge amounts of data. One 
 hypothesis is that the merkle tree precision may deteriorate too much at some 
 data size. To check this hypothesis, it would be reasonably to gather 
 statistic during the merkle tree building of how many rows each merkle tree 
 range account for (and the size that this represent). It is probably an 
 interesting statistic to have anyway.   

--
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-5243) cassandra-stress aggregate statistics

2013-02-12 Thread Ryan McGuire (JIRA)

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

Ryan McGuire updated CASSANDRA-5243:


Attachment: (was: trunk-5243.txt)

 cassandra-stress aggregate statistics
 -

 Key: CASSANDRA-5243
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5243
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Ryan McGuire
Assignee: Ryan McGuire
Priority: Minor
 Attachments: trunk-5243.txt


 cassandra-stress should output some aggregated statistics for the data that 
 it outputs. In testing the performance of a Cassandra cluster it's useful to 
 look at the performance by establishing what the average read/write rate is 
 during the middle 80% of a stress job (the first and last 10% being outliers 
 as the cluster is starting and stopping a big operation.)
 I've implemented this to add these stats to the end of the cassandra-stress 
 output. It also adds a command line option to turn it off if it's not desired.
 My branch here: 
 https://github.com/EnigmaCurry/cassandra/commit/157993d087015b17267e613a458d5bc8bd36a888

--
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-5243) cassandra-stress aggregate statistics

2013-02-12 Thread Ryan McGuire (JIRA)

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

Ryan McGuire updated CASSANDRA-5243:


Attachment: trunk-5243.txt

I uploaded a fixed patch (the direction was reversed on the previous one)

 cassandra-stress aggregate statistics
 -

 Key: CASSANDRA-5243
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5243
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Ryan McGuire
Assignee: Ryan McGuire
Priority: Minor
 Attachments: trunk-5243.txt


 cassandra-stress should output some aggregated statistics for the data that 
 it outputs. In testing the performance of a Cassandra cluster it's useful to 
 look at the performance by establishing what the average read/write rate is 
 during the middle 80% of a stress job (the first and last 10% being outliers 
 as the cluster is starting and stopping a big operation.)
 I've implemented this to add these stats to the end of the cassandra-stress 
 output. It also adds a command line option to turn it off if it's not desired.
 My branch here: 
 https://github.com/EnigmaCurry/cassandra/commit/157993d087015b17267e613a458d5bc8bd36a888

--
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: Add aggregate statistics to cassandra-stress Patch by Ryan McGuire, reviewed by brandonwilliams for CASSANDRA-5243

2013-02-12 Thread brandonwilliams
Updated Branches:
  refs/heads/trunk dd4d798dc - c1e5b0ffa


Add aggregate statistics to cassandra-stress
Patch by Ryan McGuire, reviewed by brandonwilliams for CASSANDRA-5243


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

Branch: refs/heads/trunk
Commit: c1e5b0ffafd28411ef2c36ace94bf011c0484b3f
Parents: dd4d798
Author: Brandon Williams brandonwilli...@apache.org
Authored: Tue Feb 12 15:12:59 2013 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Tue Feb 12 15:12:59 2013 -0600

--
 .../src/org/apache/cassandra/stress/Session.java   |   12 ++
 .../org/apache/cassandra/stress/StressAction.java  |   19 ++-
 .../apache/cassandra/stress/StressStatistics.java  |  124 +++
 3 files changed, 152 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1e5b0ff/tools/stress/src/org/apache/cassandra/stress/Session.java
--
diff --git a/tools/stress/src/org/apache/cassandra/stress/Session.java 
b/tools/stress/src/org/apache/cassandra/stress/Session.java
index 804e4e8..58181a0 100644
--- a/tools/stress/src/org/apache/cassandra/stress/Session.java
+++ b/tools/stress/src/org/apache/cassandra/stress/Session.java
@@ -108,6 +108,7 @@ public class Session implements Serializable
 availableOptions.addOption(Z,  compaction-strategy,  true,   
CompactionStrategy to use.);
 availableOptions.addOption(U,  comparator,   true,   
Column Comparator to use. Currently supported types are: TimeUUIDType, 
AsciiType, UTF8Type.);
 availableOptions.addOption(tf, transport-factory,true,   
Fully-qualified TTransportFactory class name for creating a connection. Note: 
For Thrift over SSL, use org.apache.cassandra.stress.SSLTransportFactory.);
+availableOptions.addOption(ns, no-statistics,false,  Turn 
off the aggegate statistics that is normally output after completion.);
 availableOptions.addOption(ts, SSL_TRUSTSTORE, true, SSL: 
full path to truststore);
 availableOptions.addOption(tspw, SSL_TRUSTSTORE_PW,true, SSL: 
full path to truststore);
 availableOptions.addOption(prtcl, SSL_PROTOCOL,true, SSL: 
connections protocol to use (default: TLS));
@@ -138,6 +139,7 @@ public class Session implements Serializable
 private boolean enable_cql= false;
 private boolean use_prepared  = false;
 private boolean trace = false;
+private boolean captureStatistics = true;
 
 private final String outFileName;
 
@@ -405,6 +407,11 @@ public class Session implements Serializable
 timeUUIDComparator = false;
 }
 
+if (cmd.hasOption(ns))
+{
+captureStatistics = false;
+}
+
 if(cmd.hasOption(SSL_TRUSTSTORE))
 encOptions.truststore = cmd.getOptionValue(SSL_TRUSTSTORE);
 
@@ -582,6 +589,11 @@ public class Session implements Serializable
 return use_prepared;
 }
 
+public boolean outputStatistics()
+{
+return captureStatistics;
+}
+
 /**
  * Create Keyspace with Standard and Super/Counter column families
  */

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1e5b0ff/tools/stress/src/org/apache/cassandra/stress/StressAction.java
--
diff --git a/tools/stress/src/org/apache/cassandra/stress/StressAction.java 
b/tools/stress/src/org/apache/cassandra/stress/StressAction.java
index ca71aba..9aa128f 100644
--- a/tools/stress/src/org/apache/cassandra/stress/StressAction.java
+++ b/tools/stress/src/org/apache/cassandra/stress/StressAction.java
@@ -89,6 +89,8 @@ public class StressAction extends Thread
 int interval = client.getProgressInterval();
 int epochIntervals = client.getProgressInterval() * 10;
 long testStartTime = System.currentTimeMillis();
+
+StressStatistics stats = new StressStatistics(client, output);
 
 while (!terminate)
 {
@@ -142,6 +144,14 @@ public class StressAction extends Thread
  keyDelta / interval,
  latency.getMedian(), 
latency.get95thPercentile(), latency.get999thPercentile(),
  currentTimeInSeconds));
+
+if (client.outputStatistics()) {
+stats.addIntervalStats(total, 
+   opDelta / interval, 
+   keyDelta / 

[jira] [Commented] (CASSANDRA-4775) Counters 2.0

2013-02-12 Thread Srdjan Mitrovic (JIRA)

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

Srdjan Mitrovic commented on CASSANDRA-4775:


bq. Not sure we'd want to support avg (since it requires extra information to 
be stored, as you point out)
If we record every incr operation we will have extra info (until compaction :( )

I will propose a way you can make idempotent counters work and have all these 
features.
1. Create a CF with columns replayID, counterName, value, cnt and optional 
columns customField1, customField2, 
(Random partitioner on replayID or if we want to be sure it is unique we can 
use ComposityType replayID:counterName
2. Create a secondary index on counterName that we use to find sum(value) on 
each node separately because secondary index is distributed. 
3. on compaction we delete old replayID, find total of value*cnt and sum(cnt) 
and store a new row (replayId, counterName, total, new cnt)

We can use increment operation with some count (this will affect avg). For 
example incr(counters, myCounter, replayId, 3, 5) which will increment counter 
by 15 but it will be stored as value 3, cnt 5 so that it affects average.

We can create custom fields for some reduce(IterableColumn so that we can 
support min, max, AND/OR/XOR...

It would be ideal if a secondary index could also store values of the columns 
so that we can read counters in one go on each node. There is another jira 
issue for this. After that issue is resolved we can only keep secondary index 
without original CF, we just pretend it exists :)


 Counters 2.0
 

 Key: CASSANDRA-4775
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Arya Goudarzi
  Labels: counters
 Fix For: 2.0


 The existing partitioned counters remain a source of frustration for most 
 users almost two years after being introduced.  The remaining problems are 
 inherent in the design, not something that can be fixed given enough 
 time/eyeballs.
 Ideally a solution would give us
 - similar performance
 - less special cases in the code
 - potential for a retry mechanism

--
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-5246) Tables Created via CQL Not Visible in CLI

2013-02-12 Thread Russell Bradberry (JIRA)
Russell Bradberry created CASSANDRA-5246:


 Summary: Tables Created via CQL Not Visible in CLI
 Key: CASSANDRA-5246
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5246
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1
Reporter: Russell Bradberry


When creating tables in CQL, the tables do not show up in the `show schema` 
command in the cli.

To recreate:

{code}
$ cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.3.0 | Cassandra 1.2.0 | CQL spec 3.0.0 | Thrift protocol 19.35.0]
Use HELP for help.
cqlsh CREATE KEYSPACE my_test WITH replication = { 'class': 
'NetworkTopologyStrategy',  'datacenter1': '1' };
cqlsh USE my_test;
cqlsh:my_test CREATE TABLE lolwut ( col1 text, col2 text, col3 text, PRIMARY 
KEY (col1));
cqlsh:my_test DESCRIBE TABLES;

lolwut

cqlsh:my_test exit

$ cassandra-cli -k my_test;
Connected to: Test Cluster on 127.0.0.1/9160
Welcome to Cassandra CLI version 1.2.1

Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.

[default@my_test] show schema;
create keyspace my_test
  with placement_strategy = 'NetworkTopologyStrategy'
  and strategy_options = {datacenter1 : 1}
  and durable_writes = true;

use my_test;



[default@my_test] list lolwut;
Using default limit of 100
Using default column limit of 100

0 Row Returned.
Elapsed time: 21 msec(s).
[default@my_test] describe lolwut;
ColumnFamily: lolwut
  Key Validation Class: org.apache.cassandra.db.marshal.UTF8Type
  Default column value validator: org.apache.cassandra.db.marshal.BytesType
  Columns sorted by: 
org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type)
  GC grace seconds: 0
  Compaction min/max thresholds: 0/0
  Read repair chance: 0.0
  DC Local Read repair chance: 0.0
  Replicate on write: false
  Caching: keys_only
  Bloom Filter FP chance: default
  Built indexes: []
  Compaction Strategy: null
{code}


--
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-2698) Instrument repair to be able to assess it's efficiency (precision)

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-2698:
--

Assignee: Yuki Morishita

 Instrument repair to be able to assess it's efficiency (precision)
 --

 Key: CASSANDRA-2698
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2698
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Yuki Morishita
Priority: Minor
  Labels: lhf
 Attachments: nodetool_repair_and_cfhistogram.tar.gz, patch_2698_v1.txt


 Some reports indicate that repair sometime transfer huge amounts of data. One 
 hypothesis is that the merkle tree precision may deteriorate too much at some 
 data size. To check this hypothesis, it would be reasonably to gather 
 statistic during the merkle tree building of how many rows each merkle tree 
 range account for (and the size that this represent). It is probably an 
 interesting statistic to have anyway.   

--
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-2698) Instrument repair to be able to assess it's efficiency (precision)

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-2698:
--

Reviewer: jbellis  (was: yukim)
Assignee: (was: Yuki Morishita)

 Instrument repair to be able to assess it's efficiency (precision)
 --

 Key: CASSANDRA-2698
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2698
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Priority: Minor
  Labels: lhf
 Attachments: nodetool_repair_and_cfhistogram.tar.gz, patch_2698_v1.txt


 Some reports indicate that repair sometime transfer huge amounts of data. One 
 hypothesis is that the merkle tree precision may deteriorate too much at some 
 data size. To check this hypothesis, it would be reasonably to gather 
 statistic during the merkle tree building of how many rows each merkle tree 
 range account for (and the size that this represent). It is probably an 
 interesting statistic to have anyway.   

--
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-4775) Counters 2.0

2013-02-12 Thread Srdjan Mitrovic (JIRA)

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

Srdjan Mitrovic edited comment on CASSANDRA-4775 at 2/12/13 9:58 PM:
-

bq. Not sure we'd want to support avg (since it requires extra information to 
be stored, as you point out)
If we record every incr operation we will have extra info (until compaction :( )

I will propose a way you can make idempotent counters work and have all these 
features.
1. Create a CF with columns replayID, counterName, value, cnt and optional 
columns customField1, customField2, 
(Random partitioner on replayID or if we want to be sure it is unique we can 
use ComposityType replayID:counterName
2. Create a secondary index on counterName that we use to find sum(value) on 
each node separately because secondary index is distributed. 
3. on compaction we delete old replayID, find total of value*cnt and sum(cnt) 
and store a new row (replayId, counterName, total, new cnt)

We can use increment operation with some count (this will affect avg). For 
example incr(counters, myCounter, replayId, 3, 5) which will increment counter 
by 15 but it will be stored as value 3, cnt 5 so that it affects average in a 
different way than incrementing by value 15, count 1.

We can create custom fields for some reduce(IterableColumn so that we can 
support min, max, AND/OR/XOR...

It would be ideal if a secondary index could also store values of the columns 
so that we can read counters in one go on each node. There is another jira 
issue for this. After that issue is resolved we can only keep secondary index 
without original CF, we just pretend it exists :)


  was (Author: stecak):
bq. Not sure we'd want to support avg (since it requires extra information 
to be stored, as you point out)
If we record every incr operation we will have extra info (until compaction :( )

I will propose a way you can make idempotent counters work and have all these 
features.
1. Create a CF with columns replayID, counterName, value, cnt and optional 
columns customField1, customField2, 
(Random partitioner on replayID or if we want to be sure it is unique we can 
use ComposityType replayID:counterName
2. Create a secondary index on counterName that we use to find sum(value) on 
each node separately because secondary index is distributed. 
3. on compaction we delete old replayID, find total of value*cnt and sum(cnt) 
and store a new row (replayId, counterName, total, new cnt)

We can use increment operation with some count (this will affect avg). For 
example incr(counters, myCounter, replayId, 3, 5) which will increment counter 
by 15 but it will be stored as value 3, cnt 5 so that it affects average.

We can create custom fields for some reduce(IterableColumn so that we can 
support min, max, AND/OR/XOR...

It would be ideal if a secondary index could also store values of the columns 
so that we can read counters in one go on each node. There is another jira 
issue for this. After that issue is resolved we can only keep secondary index 
without original CF, we just pretend it exists :)

  
 Counters 2.0
 

 Key: CASSANDRA-4775
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Arya Goudarzi
  Labels: counters
 Fix For: 2.0


 The existing partitioned counters remain a source of frustration for most 
 users almost two years after being introduced.  The remaining problems are 
 inherent in the design, not something that can be fixed given enough 
 time/eyeballs.
 Ideally a solution would give us
 - similar performance
 - less special cases in the code
 - potential for a retry mechanism

--
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-5246) Tables Created via CQL Not Visible in CLI

2013-02-12 Thread Russell Bradberry (JIRA)

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

Russell Bradberry updated CASSANDRA-5246:
-

Description: 
When creating tables in CQL, the tables do not show up in the `show schema` 
command in the cli.

To recreate:

{code}
$ cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.3.0 | Cassandra 1.2.1 | CQL spec 3.0.0 | Thrift protocol 19.35.0]
Use HELP for help.
cqlsh CREATE KEYSPACE my_test WITH replication = { 'class': 
'NetworkTopologyStrategy',  'datacenter1': '1' };
cqlsh USE my_test;
cqlsh:my_test CREATE TABLE lolwut ( col1 text, col2 text, col3 text, PRIMARY 
KEY (col1));
cqlsh:my_test DESCRIBE TABLES;

lolwut

cqlsh:my_test exit

$ cassandra-cli -k my_test;
Connected to: Test Cluster on 127.0.0.1/9160
Welcome to Cassandra CLI version 1.2.1

Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.

[default@my_test] show schema;
create keyspace my_test
  with placement_strategy = 'NetworkTopologyStrategy'
  and strategy_options = {datacenter1 : 1}
  and durable_writes = true;

use my_test;



[default@my_test] list lolwut;
Using default limit of 100
Using default column limit of 100

0 Row Returned.
Elapsed time: 21 msec(s).
[default@my_test] describe lolwut;
ColumnFamily: lolwut
  Key Validation Class: org.apache.cassandra.db.marshal.UTF8Type
  Default column value validator: org.apache.cassandra.db.marshal.BytesType
  Columns sorted by: 
org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type)
  GC grace seconds: 0
  Compaction min/max thresholds: 0/0
  Read repair chance: 0.0
  DC Local Read repair chance: 0.0
  Replicate on write: false
  Caching: keys_only
  Bloom Filter FP chance: default
  Built indexes: []
  Compaction Strategy: null
{code}


  was:
When creating tables in CQL, the tables do not show up in the `show schema` 
command in the cli.

To recreate:

{code}
$ cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.3.0 | Cassandra 1.2.0 | CQL spec 3.0.0 | Thrift protocol 19.35.0]
Use HELP for help.
cqlsh CREATE KEYSPACE my_test WITH replication = { 'class': 
'NetworkTopologyStrategy',  'datacenter1': '1' };
cqlsh USE my_test;
cqlsh:my_test CREATE TABLE lolwut ( col1 text, col2 text, col3 text, PRIMARY 
KEY (col1));
cqlsh:my_test DESCRIBE TABLES;

lolwut

cqlsh:my_test exit

$ cassandra-cli -k my_test;
Connected to: Test Cluster on 127.0.0.1/9160
Welcome to Cassandra CLI version 1.2.1

Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.

[default@my_test] show schema;
create keyspace my_test
  with placement_strategy = 'NetworkTopologyStrategy'
  and strategy_options = {datacenter1 : 1}
  and durable_writes = true;

use my_test;



[default@my_test] list lolwut;
Using default limit of 100
Using default column limit of 100

0 Row Returned.
Elapsed time: 21 msec(s).
[default@my_test] describe lolwut;
ColumnFamily: lolwut
  Key Validation Class: org.apache.cassandra.db.marshal.UTF8Type
  Default column value validator: org.apache.cassandra.db.marshal.BytesType
  Columns sorted by: 
org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type)
  GC grace seconds: 0
  Compaction min/max thresholds: 0/0
  Read repair chance: 0.0
  DC Local Read repair chance: 0.0
  Replicate on write: false
  Caching: keys_only
  Bloom Filter FP chance: default
  Built indexes: []
  Compaction Strategy: null
{code}



 Tables Created via CQL Not Visible in CLI
 -

 Key: CASSANDRA-5246
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5246
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1
Reporter: Russell Bradberry

 When creating tables in CQL, the tables do not show up in the `show schema` 
 command in the cli.
 To recreate:
 {code}
 $ cqlsh -3
 Connected to Test Cluster at localhost:9160.
 [cqlsh 2.3.0 | Cassandra 1.2.1 | CQL spec 3.0.0 | Thrift protocol 19.35.0]
 Use HELP for help.
 cqlsh CREATE KEYSPACE my_test WITH replication = { 'class': 
 'NetworkTopologyStrategy',  'datacenter1': '1' };
 cqlsh USE my_test;
 cqlsh:my_test CREATE TABLE lolwut ( col1 text, col2 text, col3 text, PRIMARY 
 KEY (col1));
 cqlsh:my_test DESCRIBE TABLES;
 lolwut
 cqlsh:my_test exit
 $ cassandra-cli -k my_test;
 Connected to: Test Cluster on 127.0.0.1/9160
 Welcome to Cassandra CLI version 1.2.1
 Type 'help;' or '?' for help.
 Type 'quit;' or 'exit;' to quit.
 [default@my_test] show schema;
 create keyspace my_test
   with placement_strategy = 'NetworkTopologyStrategy'
   and strategy_options = {datacenter1 : 1}
   and durable_writes = true;
 use my_test;
 [default@my_test] list lolwut;
 Using default limit of 100
 Using default column limit of 100
 0 

[jira] [Resolved] (CASSANDRA-5246) Tables Created via CQL Not Visible in CLI

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis resolved CASSANDRA-5246.
---

Resolution: Not A Problem

This is by design.  CLI and Thrift-based consumers in general do not know how 
to understand CQL3 metadata, and would do the Wrong Thing without realizing it.

 Tables Created via CQL Not Visible in CLI
 -

 Key: CASSANDRA-5246
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5246
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1
Reporter: Russell Bradberry

 When creating tables in CQL, the tables do not show up in the `show schema` 
 command in the cli.
 To recreate:
 {code}
 $ cqlsh -3
 Connected to Test Cluster at localhost:9160.
 [cqlsh 2.3.0 | Cassandra 1.2.1 | CQL spec 3.0.0 | Thrift protocol 19.35.0]
 Use HELP for help.
 cqlsh CREATE KEYSPACE my_test WITH replication = { 'class': 
 'NetworkTopologyStrategy',  'datacenter1': '1' };
 cqlsh USE my_test;
 cqlsh:my_test CREATE TABLE lolwut ( col1 text, col2 text, col3 text, PRIMARY 
 KEY (col1));
 cqlsh:my_test DESCRIBE TABLES;
 lolwut
 cqlsh:my_test exit
 $ cassandra-cli -k my_test;
 Connected to: Test Cluster on 127.0.0.1/9160
 Welcome to Cassandra CLI version 1.2.1
 Type 'help;' or '?' for help.
 Type 'quit;' or 'exit;' to quit.
 [default@my_test] show schema;
 create keyspace my_test
   with placement_strategy = 'NetworkTopologyStrategy'
   and strategy_options = {datacenter1 : 1}
   and durable_writes = true;
 use my_test;
 [default@my_test] list lolwut;
 Using default limit of 100
 Using default column limit of 100
 0 Row Returned.
 Elapsed time: 21 msec(s).
 [default@my_test] describe lolwut;
 ColumnFamily: lolwut
   Key Validation Class: org.apache.cassandra.db.marshal.UTF8Type
   Default column value validator: 
 org.apache.cassandra.db.marshal.BytesType
   Columns sorted by: 
 org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type)
   GC grace seconds: 0
   Compaction min/max thresholds: 0/0
   Read repair chance: 0.0
   DC Local Read repair chance: 0.0
   Replicate on write: false
   Caching: keys_only
   Bloom Filter FP chance: default
   Built indexes: []
   Compaction Strategy: null
 {code}

--
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-5211) Migrating Clusters with gossip tables that have old dead nodes causes NPE, inability to join cluster

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-5211:
---

+1

 Migrating Clusters with gossip tables that have old dead nodes causes NPE, 
 inability to join cluster
 

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

 Attachments: 5211.txt


 I had done a removetoken on this cluster when it was 1.1.x, and it had a 
 ghost entry for the removed node still in the stored ring data. When the 
 nodes loaded the table up after conversion to 1.2 and attempting to migrate 
 to VNodes, I got the following traceback:
 ERROR [WRITE-/10.0.0.0] 2013-01-31 18:35:44,788 CassandraDaemon.java (line 
 133) Exception in thread Thread[WRITE-/10.0.0.0,5,main]
 java.lang.NullPointerException
   at 
 org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
   at 
 org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
   at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:73)
   at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:93)
   at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:32)
   at 
 org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:96)
   at 
 org.apache.cassandra.db.SystemTable.loadDcRackInfo(SystemTable.java:402)
   at 
 org.apache.cassandra.locator.Ec2Snitch.getDatacenter(Ec2Snitch.java:117)
   at 
 org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:127)
   at 
 org.apache.cassandra.net.OutboundTcpConnection.isLocalDC(OutboundTcpConnection.java:74)
   at 
 org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:270)
   at 
 org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:142)
 This is because these ghost nodes had a NULL tokens list in the system/peers 
 table. A workaround was to delete the offending row in the system/peers table 
 and restart the node.

--
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-4784) Create separate sstables for each token range handled by a node

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-4784:
---

The data itself could still be sequential on disk even if the blocks belong to 
different files...  Not sure how much overhead the file creation itself would 
have.  Certainly worth testing.

 Create separate sstables for each token range handled by a node
 ---

 Key: CASSANDRA-4784
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4784
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: sankalp kohli
Assignee: Benjamin Coverston
Priority: Minor
  Labels: perfomance
 Fix For: 2.0

 Attachments: 4784.patch


 Currently, each sstable has data for all the ranges that node is handling. If 
 we change that and rather have separate sstables for each range that node is 
 handling, it can lead to some improvements.
 Improvements
 1) Node rebuild will be very fast as sstables can be directly copied over to 
 the bootstrapping node. It will minimize any application level logic. We can 
 directly use Linux native methods to transfer sstables without using CPU and 
 putting less pressure on the serving node. I think in theory it will be the 
 fastest way to transfer data. 
 2) Backup can only transfer sstables for a node which belong to its primary 
 keyrange. 
 3) ETL process can only copy one replica of data and will be much faster. 
 Changes:
 We can split the writes into multiple memtables for each range it is 
 handling. The sstables being flushed from these can have details of which 
 range of data it is handling.
 There will be no change I think for any reads as they work with interleaved 
 data anyway. But may be we can improve there as well? 
 Complexities:
 The change does not look very complicated. I am not taking into account how 
 it will work when ranges are being changed for nodes. 
 Vnodes might make this work more complicated. We can also have a bit on each 
 sstable which says whether it is primary data or not. 

--
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-4784) Create separate sstables for each token range handled by a node

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-4784:
---

Someone (Axel at Spotify?) pointed out to me that another use case here would 
be mapping different vnodes to separate disks so that on disk failure, we can 
invalidate the affected vnodes and repair them, rather than continuing to serve 
incomplete data or halting the entire node.

 Create separate sstables for each token range handled by a node
 ---

 Key: CASSANDRA-4784
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4784
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: sankalp kohli
Assignee: Benjamin Coverston
Priority: Minor
  Labels: perfomance
 Fix For: 2.0

 Attachments: 4784.patch


 Currently, each sstable has data for all the ranges that node is handling. If 
 we change that and rather have separate sstables for each range that node is 
 handling, it can lead to some improvements.
 Improvements
 1) Node rebuild will be very fast as sstables can be directly copied over to 
 the bootstrapping node. It will minimize any application level logic. We can 
 directly use Linux native methods to transfer sstables without using CPU and 
 putting less pressure on the serving node. I think in theory it will be the 
 fastest way to transfer data. 
 2) Backup can only transfer sstables for a node which belong to its primary 
 keyrange. 
 3) ETL process can only copy one replica of data and will be much faster. 
 Changes:
 We can split the writes into multiple memtables for each range it is 
 handling. The sstables being flushed from these can have details of which 
 range of data it is handling.
 There will be no change I think for any reads as they work with interleaved 
 data anyway. But may be we can improve there as well? 
 Complexities:
 The change does not look very complicated. I am not taking into account how 
 it will work when ranges are being changed for nodes. 
 Vnodes might make this work more complicated. We can also have a bit on each 
 sstable which says whether it is primary data or not. 

--
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-5247) cassandra-cli should exit with error-exit status on all errors which cause it to exit.

2013-02-12 Thread Robert P. Thille (JIRA)
Robert P. Thille created CASSANDRA-5247:
---

 Summary: cassandra-cli should exit with error-exit status on all 
errors which cause it to exit.
 Key: CASSANDRA-5247
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5247
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.2.1
Reporter: Robert P. Thille
Priority: Minor


running cassandra-cli with a --file argument which does not exist returns 
success:
ubuntu@host:~$ cassandra-cli --file does-not-exist ; echo $?
does-not-exist (No such file or directory)
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-5139) Drop keyspace argument from forceUserDefinedCompactions

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-5139:
---

+1

 Drop keyspace argument from forceUserDefinedCompactions
 ---

 Key: CASSANDRA-5139
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5139
 Project: Cassandra
  Issue Type: Bug
Reporter: Jonathan Ellis
Assignee: Yuki Morishita
Priority: Minor
  Labels: jmx
 Fix For: 2.0

 Attachments: 5139-2.0.txt, 5139.txt


 Redundant now that keyspace is encoded in filename.

--
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-5105) repair -pr throws EOFException

2013-02-12 Thread Yuki Morishita (JIRA)

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

Yuki Morishita updated CASSANDRA-5105:
--

Attachment: 0002-fix-compressed-streaming-sends-extra-chunk.patch
0001-add-CompressedInputStream-test.patch

I found one problem that can send extra chunk to destination which causes 
reading from wrong position.
This happens when the streaming section of sstable falls into the edge of 
compression chunks.
Test and fix attached.

 repair -pr throws EOFException
 --

 Key: CASSANDRA-5105
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5105
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0
 Environment: Ubuntu 12.04 Java 7
Reporter: Michael Kjellman
Assignee: Yuki Morishita
Priority: Minor
 Attachments: 0001-add-CompressedInputStream-test.patch, 
 0002-fix-compressed-streaming-sends-extra-chunk.patch


 nodetool repair -pr threw an EOF exception
 {code:title=node1}
 ERROR 12:50:18,723 Exception in thread Thread[Streaming to 
 /10.8.25.113:1,5,main]
 java.lang.RuntimeException: java.io.EOFException
   at com.google.common.base.Throwables.propagate(Throwables.java:160)
   at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 Caused by: java.io.EOFException
   at java.io.DataInputStream.readInt(DataInputStream.java:375)
   at 
 org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
   at 
 org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
   at 
 org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
   at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
 {code}
 {code:title=node2}
  INFO 12:49:45,139 Finished streaming session to /10.8.30.13
 ERROR 12:50:18,799 Exception in thread Thread[Thread-4031,5,main]
 java.lang.RuntimeException: Last written key 
 DecoratedKey(167625858728826091814875924785363245309, 
 6634333531356661643161636636373738353431363162353031376164386339) = current 
 ke
 y DecoratedKey(33957321636818582219838207277782228619, 
 696c2e636f6d200a3c42523e0a3c42523e0a5472656e7420202020202020202020202020202020422e204d697261636c652020202020202020202020202
 020202020202020202020202020202020202020202020202020202020200a2020266e62737020266e62737020746d697261636c654073696d6d6f6e736669726d2e636f6d2c206c776f6f74656e4073696d6d6f6e736669726
 d2e636f6d203c42523e0a3c42523e0a56616e636520202020202020202020202020202020522e20416e64727573202020202020202020202020202020202020202020202020202020202020202020202020202020202020200
 a2020266e62737020266e627370207672614061622d706c632e636f6d203c42523e0a3c42523e0a5665726e6f6e202020202020202020202020202020462e20476c656e6e20202020202020202020202020202020202020202
 020202020202020202020202020202020202020202020200a2020266e62737020266e62737020676c656e6e6c6177406c6f77636f756e7472796c61777965722e636f6d203c42523e0a3c42523e0a56696e63656e742020202
 0202020202020202020204a2e20446573616c766f2020202020202020202020202020202020202020202020202020202020202020202020202020202020200a2020266e62737020266e6273702076646573616c766f4064657
 3616c766f6c61776669726d2e636f6d203c42523e0a3c42523e0a56696e63656e7420202020202020202020202020204a616d65732043617274657220202020202020202020202020202020202020202020202020202020202
 0202020202020202020200a2020202020266e62737020266e627370207663617274657240676972617264696b656573652e636f6d2c207479616d6173616b6940676972617264696b656573652e636f6d203c42523e0a0a3c4
 2523e0a572e202020202020202020202020202020202020204a616d65732053696e676c65746f6e202020202020202020202020202020202020202020202020202020202020202020202020200a2020202020266e627370202...trunkated...324132393239413134333439413834453531394133373431)
  writing into 
 /data/cassandra/evidence/fingerprints/evidence-fingerprints-tmp-ia-161-Data.db
 at 
 org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:133)
 at 
 org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:209)
 at 
 org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
 at 
 org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
 at 
 org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:226)
 at 
 org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:166)
 at 
 

[jira] [Commented] (CASSANDRA-4795) replication, compaction, compression? options are not validated

2013-02-12 Thread Pavel Yaskevich (JIRA)

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

Pavel Yaskevich commented on CASSANDRA-4795:


bq. But fundamentally creating a last_seen_versions table with cfname (ksname?) 
is simply not that onerous and is the Right Thing To Do.

For that specific case it's actually not worth it because it's always a single 
version as there is no reason to keep older version around, so creating 
separate CF for one row with empty value is overkill as specially as it's even 
not read that often and query wouldn't be as convenient as it was with describe 
keyspace for that single piece of data.

bq. -1 from me, I get that change is painful for people who are abusing schema 
right now but we really shouldn't be encouraging this.

It's usually one/two attributes that go there so I think it's pretty convenient 
to store it that way instead of dealing with separate CF/querying, but I'm 
welcome to new ideas

 replication, compaction, compression? options are not validated
 ---

 Key: CASSANDRA-4795
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4795
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Brandon Williams
Assignee: Dave Brosius
Priority: Minor
 Fix For: 1.2.1

 Attachments: 0001-Reallow-unexpected-strategy-options-for-thrift.txt, 
 0002-Reallow-unexpected-strategy-options-for-thrift.txt, 
 0003-Adds-application_metadata-field-to-ks-metadata.txt, 
 4795.compaction_strategy.txt, 4795_compaction_strategy_v2.txt, 
 4795_compaction_strategy_v3.txt, 4795.replication_strategy.txt


 When creating a keyspace and specifying strategy options, you can pass any 
 k/v pair you like.

--
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-4795) replication, compaction, compression? options are not validated

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-4795:
---

Show me an existing database that lets you attach random crap to a table 
definition and I will reconsider my position. :)

 replication, compaction, compression? options are not validated
 ---

 Key: CASSANDRA-4795
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4795
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Brandon Williams
Assignee: Dave Brosius
Priority: Minor
 Fix For: 1.2.1

 Attachments: 0001-Reallow-unexpected-strategy-options-for-thrift.txt, 
 0002-Reallow-unexpected-strategy-options-for-thrift.txt, 
 0003-Adds-application_metadata-field-to-ks-metadata.txt, 
 4795.compaction_strategy.txt, 4795_compaction_strategy_v2.txt, 
 4795_compaction_strategy_v3.txt, 4795.replication_strategy.txt


 When creating a keyspace and specifying strategy options, you can pass any 
 k/v pair you like.

--
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-4775) Counters 2.0

2013-02-12 Thread Srdjan Mitrovic (JIRA)

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

Srdjan Mitrovic edited comment on CASSANDRA-4775 at 2/12/13 10:39 PM:
--

bq. Not sure we'd want to support avg (since it requires extra information to 
be stored, as you point out)
If we record every incr operation we will have extra info (until compaction :( )

I will propose a way you can make idempotent counters work and have all these 
features.
1. Create a CF with columns replayID, counterName, value, cnt and optional 
columns customField1, customField2, 
(Random partitioner on replayID or if we want to be sure it is unique we can 
use ComposityType replayID:counterName
2. Create a secondary index on counterName that we use to find sum(value) on 
each node separately because secondary index is distributed. 
3. On compaction we delete old replayID, find total of value*cnt and sum(cnt) 
and store a new row (replayId, counterName, total, new cnt)

We can use increment operation with some count (this will affect avg). For 
example incr(counters, myCounter, replayId, 3, 5) which will increment counter 
by 15 but it will be stored as value 3, cnt 5 so that it affects average in a 
different way than incrementing by value 15, count 1.

We can create custom fields for some reduce(IterableColumn so that we can 
support min, max, AND/OR/XOR...For examoke on compaction we would store reduced 
max in that custom field.

It would be ideal if a secondary index could also store values of the columns 
so that we can read counters in one go on each node. There is another jira 
issue for this. After that issue is resolved we can only keep secondary index 
without original CF, we just pretend it exists :)

I guess that this approach could be achieved by clients if we have a pluggable 
compaction strategy but it would still be much easier if secondary indexes 
could also store other column values, not only keys.


  was (Author: stecak):
bq. Not sure we'd want to support avg (since it requires extra information 
to be stored, as you point out)
If we record every incr operation we will have extra info (until compaction :( )

I will propose a way you can make idempotent counters work and have all these 
features.
1. Create a CF with columns replayID, counterName, value, cnt and optional 
columns customField1, customField2, 
(Random partitioner on replayID or if we want to be sure it is unique we can 
use ComposityType replayID:counterName
2. Create a secondary index on counterName that we use to find sum(value) on 
each node separately because secondary index is distributed. 
3. on compaction we delete old replayID, find total of value*cnt and sum(cnt) 
and store a new row (replayId, counterName, total, new cnt)

We can use increment operation with some count (this will affect avg). For 
example incr(counters, myCounter, replayId, 3, 5) which will increment counter 
by 15 but it will be stored as value 3, cnt 5 so that it affects average in a 
different way than incrementing by value 15, count 1.

We can create custom fields for some reduce(IterableColumn so that we can 
support min, max, AND/OR/XOR...

It would be ideal if a secondary index could also store values of the columns 
so that we can read counters in one go on each node. There is another jira 
issue for this. After that issue is resolved we can only keep secondary index 
without original CF, we just pretend it exists :)

  
 Counters 2.0
 

 Key: CASSANDRA-4775
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Arya Goudarzi
  Labels: counters
 Fix For: 2.0


 The existing partitioned counters remain a source of frustration for most 
 users almost two years after being introduced.  The remaining problems are 
 inherent in the design, not something that can be fixed given enough 
 time/eyeballs.
 Ideally a solution would give us
 - similar performance
 - less special cases in the code
 - potential for a retry mechanism

--
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-4775) Counters 2.0

2013-02-12 Thread Srdjan Mitrovic (JIRA)

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

Srdjan Mitrovic edited comment on CASSANDRA-4775 at 2/12/13 10:43 PM:
--

bq. Not sure we'd want to support avg (since it requires extra information to 
be stored, as you point out)
If we record every incr operation we will have extra info (until compaction :( )

I will propose a way you can make idempotent counters work and have all these 
features.
1. Create a CF with columns replayID, counterName, value, cnt and optional 
columns customField1, customField2, 
(Random partitioner on replayID or if we want to be sure it is unique we can 
use ComposityType replayID:counterName
2. Create a secondary index on counterName that we use to find sum(value) on 
each node separately because secondary index is distributed. 
3. On compaction we delete old replayID, find total of value*cnt and sum(cnt) 
and store a new row (replayId, counterName, total, new cnt)

We can use increment operation with some count (this will affect avg). For 
example incr(counters, myCounter, replayId, 3, 5) which will increment counter 
by 15 but it will be stored as value 3, cnt 5 so that it affects average in a 
different way than incrementing by value 15, count 1.

We can create custom fields for some reduce(IterableColumn so that we can 
support min, max, AND/OR/XOR...For examoke on compaction we would store reduced 
max in that custom field.

These counters with replayID could be used in atomic batches. 

It would be ideal if a secondary index could also store values of the columns 
so that we can read counters in one go on each node. There is another jira 
issue for this. After that issue is resolved we can only keep secondary index 
without original CF, we just pretend it exists :)

I guess that this approach could be achieved by clients if we have a pluggable 
compaction strategy but it would still be much easier if secondary indexes 
could also store other column values, not only keys.



  was (Author: stecak):
bq. Not sure we'd want to support avg (since it requires extra information 
to be stored, as you point out)
If we record every incr operation we will have extra info (until compaction :( )

I will propose a way you can make idempotent counters work and have all these 
features.
1. Create a CF with columns replayID, counterName, value, cnt and optional 
columns customField1, customField2, 
(Random partitioner on replayID or if we want to be sure it is unique we can 
use ComposityType replayID:counterName
2. Create a secondary index on counterName that we use to find sum(value) on 
each node separately because secondary index is distributed. 
3. On compaction we delete old replayID, find total of value*cnt and sum(cnt) 
and store a new row (replayId, counterName, total, new cnt)

We can use increment operation with some count (this will affect avg). For 
example incr(counters, myCounter, replayId, 3, 5) which will increment counter 
by 15 but it will be stored as value 3, cnt 5 so that it affects average in a 
different way than incrementing by value 15, count 1.

We can create custom fields for some reduce(IterableColumn so that we can 
support min, max, AND/OR/XOR...For examoke on compaction we would store reduced 
max in that custom field.

It would be ideal if a secondary index could also store values of the columns 
so that we can read counters in one go on each node. There is another jira 
issue for this. After that issue is resolved we can only keep secondary index 
without original CF, we just pretend it exists :)

I guess that this approach could be achieved by clients if we have a pluggable 
compaction strategy but it would still be much easier if secondary indexes 
could also store other column values, not only keys.

  
 Counters 2.0
 

 Key: CASSANDRA-4775
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Arya Goudarzi
  Labels: counters
 Fix For: 2.0


 The existing partitioned counters remain a source of frustration for most 
 users almost two years after being introduced.  The remaining problems are 
 inherent in the design, not something that can be fixed given enough 
 time/eyeballs.
 Ideally a solution would give us
 - similar performance
 - less special cases in the code
 - potential for a retry mechanism

--
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: Check for the presence of both rack and dc in the system table. Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-5211

2013-02-12 Thread brandonwilliams
Check for the presence of both rack and dc in the system table.
Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-5211


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

Branch: refs/heads/trunk
Commit: 85cfd383b11db2a19109c258159b26d20e7020e5
Parents: aa7c7d9
Author: Brandon Williams brandonwilli...@apache.org
Authored: Tue Feb 12 16:55:03 2013 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Tue Feb 12 16:55:03 2013 -0600

--
 src/java/org/apache/cassandra/db/SystemTable.java |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/85cfd383/src/java/org/apache/cassandra/db/SystemTable.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemTable.java 
b/src/java/org/apache/cassandra/db/SystemTable.java
index 6a38757..adf08cc 100644
--- a/src/java/org/apache/cassandra/db/SystemTable.java
+++ b/src/java/org/apache/cassandra/db/SystemTable.java
@@ -467,7 +467,7 @@ public class SystemTable
 for (UntypedResultSet.Row row : processInternal(SELECT peer, 
data_center, rack from system. + PEERS_CF))
 {
 InetAddress peer = row.getInetAddress(peer);
-if (row.has(data_center))
+if (row.has(data_center)  row.has(rack))
 {
 MapString, String dcRack = new HashMapString, String();
 dcRack.put(data_center, row.getString(data_center));



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

2013-02-12 Thread brandonwilliams
Updated Branches:
  refs/heads/cassandra-1.2 aa7c7d9cd - 85cfd383b
  refs/heads/trunk c1e5b0ffa - 7d81f8cb5


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

Branch: refs/heads/trunk
Commit: 7d81f8cb565f5d1aab278062e44e95729e12f6da
Parents: c1e5b0f 85cfd38
Author: Brandon Williams brandonwilli...@apache.org
Authored: Tue Feb 12 16:55:39 2013 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Tue Feb 12 16:55:39 2013 -0600

--
 src/java/org/apache/cassandra/db/SystemTable.java |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7d81f8cb/src/java/org/apache/cassandra/db/SystemTable.java
--



[1/3] git commit: Check for the presence of both rack and dc in the system table. Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-5211

2013-02-12 Thread brandonwilliams
Check for the presence of both rack and dc in the system table.
Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-5211


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

Branch: refs/heads/cassandra-1.2
Commit: 85cfd383b11db2a19109c258159b26d20e7020e5
Parents: aa7c7d9
Author: Brandon Williams brandonwilli...@apache.org
Authored: Tue Feb 12 16:55:03 2013 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Tue Feb 12 16:55:03 2013 -0600

--
 src/java/org/apache/cassandra/db/SystemTable.java |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/85cfd383/src/java/org/apache/cassandra/db/SystemTable.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemTable.java 
b/src/java/org/apache/cassandra/db/SystemTable.java
index 6a38757..adf08cc 100644
--- a/src/java/org/apache/cassandra/db/SystemTable.java
+++ b/src/java/org/apache/cassandra/db/SystemTable.java
@@ -467,7 +467,7 @@ public class SystemTable
 for (UntypedResultSet.Row row : processInternal(SELECT peer, 
data_center, rack from system. + PEERS_CF))
 {
 InetAddress peer = row.getInetAddress(peer);
-if (row.has(data_center))
+if (row.has(data_center)  row.has(rack))
 {
 MapString, String dcRack = new HashMapString, String();
 dcRack.put(data_center, row.getString(data_center));



[jira] [Commented] (CASSANDRA-5229) after a IOException is thrown during streaming, streaming tasks hang in netstats

2013-02-12 Thread Yuki Morishita (JIRA)

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

Yuki Morishita commented on CASSANDRA-5229:
---

Looks like the problem is streaming session silently hangs if the exception 
thrown is not IOException(like RuntimeException in CASSANDRA-5105). When the 
error was IOException, then the node would send retry or session failure 
message.

 after a IOException is thrown during streaming, streaming tasks hang in 
 netstats
 

 Key: CASSANDRA-5229
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5229
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1
 Environment: Ubuntu 12.04
Reporter: Michael Kjellman
Priority: Critical

 After an IOExcpetion, streaming tasks marked as successful in the logs are 
 hung in netstats
 With TRACE debugging on streaming on the receiving node everything about the 
 sstable in the log (not very much)
 {code}
  INFO [AntiEntropyStage:1] 2013-02-07 11:23:44,717 StreamOut.java (line 151) 
 Stream context metadata 
 [/data/cassandra/evidence/fingerprints/evidence-fingerprints-ib-5-Data.db 
 sections=3068 progress=0/2785204713 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-25-Data.db 
 sections=2696 progress=0/758409465 - 0%, 
 /data/cassandra/evidence/fingerprints/evidence-fingerprints-ib-60-Data.db 
 sections=3099 progress=0/238876436 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-63-Data.db 
 sections=1166 progress=0/2125323 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-38-Data.db 
 sections=2507 progress=0/515992757 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-26-Data.db 
 sections=3153 progress=0/994857654 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-57-Data.db 
 sections=3116 progress=0/129398170 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-58-Data.db 
 sections=217 progress=0/72286 - 0%, 
 /data/cassandra/evidence/fingerprints/evidence-fingerprints-ib-59-Data.db 
 sections=3146 progress=0/3357709019 - 0%], 27 sstables.
  INFO [AntiEntropyStage:1] 2013-02-07 11:23:52,964 StreamOut.java (line 151) 
 Stream context metadata 
 [/data/cassandra/evidence/fingerprints/evidence-fingerprints-ib-5-Data.db 
 sections=2930 progress=0/2799914560 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-25-Data.db 
 sections=2590 progress=0/761266059 - 0%, 
 /data/cassandra/evidence/fingerprints/evidence-fingerprints-ib-60-Data.db 
 sections=2956 progress=0/241362497 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-63-Data.db 
 sections=1153 progress=0/2125323 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-38-Data.db 
 sections=2422 progress=0/522126371 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-26-Data.db 
 sections=3004 progress=0/998401202 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-57-Data.db 
 sections=2974 progress=0/129722346 - 0%, 
 /data2/cassandra/evidence/fingerprints/evidence-fingerprints-ib-58-Data.db 
 sections=220 progress=0/72286 - 0%, 
 /data/cassandra/evidence/fingerprints/evidence-fingerprints-ib-59-Data.db 
 sections=2998 progress=0/3375554099 - 0%], 27 sstables.
 {code}
 node that is streaming out thinks that the streaming session was successful 
 {code}
  INFO [MiscStage:1] 2013-02-07 11:23:38,022 StreamOut.java (line 151) Stream 
 context metadata 
 [/data/cassandra/evidence/fingerprints/evidence-fingerprints-ia-472-Data.db 
 sections=1727 progress=0/210208515 - 0%, 
 /var/lib/cassandra/data2/evidence/fingerprints/evidence-fingerprints-ib-919-Data.db
  sections=1746 progress=0/119438030 - 0%, 
 /data/cassandra/evidence/fingerprints/evidence-fingerprints-ib-920-Data.db 
 sections=1681 progress=0/54498226 - 0%, 
 /var/lib/cassandra/data2/evidence/fingerprints/evidence-fingerprints-ib-922-Data.db
  sections=16 progress=0/13490 - 0%, 
 /var/lib/cassandra/data2/evidence/fingerprints/evidence-fingerprints-ib-918-Data.db
  sections=632 progress=0/70019542 - 0%, 
 /var/lib/cassandra/data2/evidence/fingerprints/evidence-fingerprints-ib-921-Data.db
  sections=1644 progress=0/39870238 - 0%, 
 /data/cassandra/evidence/fingerprints/evidence-fingerprints-ib-497-Data.db 
 sections=1569 progress=0/208331077 - 0%, 
 /var/lib/cassandra/data2/evidence/fingerprints/evidence-fingerprints-ib-923-Data.db
  sections=1572 progress=0/30870478 - 0%, 
 /var/lib/cassandra/data2/evidence/fingerprints/evidence-fingerprints-ib-925-Data.db
  sections=167 progress=0/1845123 - 0%, 
 

[jira] [Commented] (CASSANDRA-5182) Deletable rows are sometimes not removed during compaction

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-5182:
---

I'm still not comfortable with this.

If our goal is to throw out the maximum possible amount of obsolete data, we 
should perform getPosition across the board.

But if our goal is to be minimally impactful with compaction then we shouldn't 
do it at all, and rely instead on the timestamp check.  If that's not enough, 
then you shouldn't disable bloom filters on workloads that perform deletes.  
I'm okay with that message.

 Deletable rows are sometimes not removed during compaction
 --

 Key: CASSANDRA-5182
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5182
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.7
Reporter: Binh Van Nguyen
Assignee: Yuki Morishita
 Fix For: 1.2.2

 Attachments: 5182-1.1.txt, 5182-1.2.txt, test_ttl.tar.gz


 Our use case is write heavy and read seldom.  To optimize the space used, 
 we've set the bloom_filter_fp_ratio=1.0  That along with the fact that each 
 row is only written to one time and that there are more than 20 SSTables 
 keeps the rows from ever being compacted. Here is the code:
 https://github.com/apache/cassandra/blob/cassandra-1.1/src/java/org/apache/cassandra/db/compaction/CompactionController.java#L162
 We hit this conner case and because of this C* keeps consuming more and more 
 space on disk while it should not.

--
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-5182) Deletable rows are sometimes not removed during compaction

2013-02-12 Thread Bryan Talbot (JIRA)

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

Bryan Talbot commented on CASSANDRA-5182:
-

Our use case doesn't require maximum effort to delete rows.  What we ran into 
was an unexpected interaction between two features: bloom filter tuned for low 
read rate, and deleting tombstoned rows.  With that configuration NO rows were 
being removed.  

As long as there is some reasonable effort to remove rows with bloom filter 
disabled OR it's clearly known that a reasonable FP setting is required to 
remove tombstones, I think we could have avoided a lot of headaches.

How does the new tombstone histogram feature in 1.2 affect this issue?  If that 
feature solves the problem already, maybe this fix is irrelevant.


 Deletable rows are sometimes not removed during compaction
 --

 Key: CASSANDRA-5182
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5182
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.7
Reporter: Binh Van Nguyen
Assignee: Yuki Morishita
 Fix For: 1.2.2

 Attachments: 5182-1.1.txt, 5182-1.2.txt, test_ttl.tar.gz


 Our use case is write heavy and read seldom.  To optimize the space used, 
 we've set the bloom_filter_fp_ratio=1.0  That along with the fact that each 
 row is only written to one time and that there are more than 20 SSTables 
 keeps the rows from ever being compacted. Here is the code:
 https://github.com/apache/cassandra/blob/cassandra-1.1/src/java/org/apache/cassandra/db/compaction/CompactionController.java#L162
 We hit this conner case and because of this C* keeps consuming more and more 
 space on disk while it should not.

--
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-5222) OOM Exception during repair session with LeveledCompactionStrategy

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-5222:
---

Patch attached to implement the 2 * MAX_COMPACTING_L0 approach.  Not 100% sure 
that doValidationCompaction/CompactionInterruptedException is the right way to 
handle the abort.  Yuki?

I noticed that Validator.add already asserts that the row is in the range being 
validated, so we must be doing a range check somewhere.  Not sure where though. 
 In any case, that won't help with the OOM problem since we expect to be able 
to eliminate negligible numbers of L0 sstables that way, which is the problem 
here.

 OOM Exception during repair session with LeveledCompactionStrategy
 --

 Key: CASSANDRA-5222
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5222
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.0
 Environment: 3Gb Heap(12Gb per node RAM)
 36 nodes, 0.9 Tb of data per node, Leveled compaction strategy, SSTable size 
 =100Mb
Reporter: Ivan Sobolev
Assignee: Yuki Morishita
 Fix For: 1.1.11

 Attachments: 5222.txt, chunks.json, sstablescanner.png


 1.8 Gb of heap is consumed with 12k SSTableBoundedScanner * 140kbytes

--
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-5222) OOM Exception during repair session with LeveledCompactionStrategy

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-5222:
--

Attachment: 5222.txt

 OOM Exception during repair session with LeveledCompactionStrategy
 --

 Key: CASSANDRA-5222
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5222
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.0
 Environment: 3Gb Heap(12Gb per node RAM)
 36 nodes, 0.9 Tb of data per node, Leveled compaction strategy, SSTable size 
 =100Mb
Reporter: Ivan Sobolev
Assignee: Yuki Morishita
 Fix For: 1.1.11

 Attachments: 5222.txt, chunks.json, sstablescanner.png


 1.8 Gb of heap is consumed with 12k SSTableBoundedScanner * 140kbytes

--
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-5222) OOM Exception during repair session with LeveledCompactionStrategy

2013-02-12 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-5222:
--

Reviewer: yukim  (was: jbellis)
Assignee: Jonathan Ellis  (was: Yuki Morishita)

 OOM Exception during repair session with LeveledCompactionStrategy
 --

 Key: CASSANDRA-5222
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5222
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.0
 Environment: 3Gb Heap(12Gb per node RAM)
 36 nodes, 0.9 Tb of data per node, Leveled compaction strategy, SSTable size 
 =100Mb
Reporter: Ivan Sobolev
Assignee: Jonathan Ellis
 Fix For: 1.1.11

 Attachments: 5222.txt, chunks.json, sstablescanner.png


 1.8 Gb of heap is consumed with 12k SSTableBoundedScanner * 140kbytes

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


[Cassandra Wiki] Trivial Update of DrusillaH by DrusillaH

2013-02-12 Thread Apache Wiki
Dear Wiki user,

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

The DrusillaH page has been changed by DrusillaH:
http://wiki.apache.org/cassandra/DrusillaH?action=diffrev1=1rev2=2

- Yo bros !! The name is LILLIAN GALLOWAY. I am from Simi Valley.BR
- I am 56. My parents want me to join The Gleeful Institute situated in Plano. 
My daddy name is Bryan and he is a Bishop. My mom is a Lyricist.BR
+ Hi !! The name is DANIELLA LOWE. I live in Tempe.BR
+ I am 22. I study at The Immediately Military School of Magic People built at 
Londonderry. My dad name is Donald and he is a Singer. My mom is a Hunter.BR
  BR
- Also visit my site [[http://www.aldorabag.com|chanel bags]]
+ my blog - [[http://www.aldorabag.com|chanel bags]]
  


[jira] [Commented] (CASSANDRA-4916) Starting Cassandra throws EOF while reading saved cache

2013-02-12 Thread Drew Kutcharian (JIRA)

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

Drew Kutcharian commented on CASSANDRA-4916:


I just saw this same exception happen on Cassandra 1.2.1. Was this part of the 
1.2.1 release?
I'm on Mac OS X 10.8.2, Oracle JDK 1.7.0_11, using snappy-java 1.0.5-M3 from 
Maven (not sure if that's the cause).

I'm attaching my data and log directory as data.zip.


 Starting Cassandra throws EOF while reading saved cache
 ---

 Key: CASSANDRA-4916
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4916
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Michael Kjellman
Assignee: Dave Brosius
Priority: Minor
 Fix For: 1.2.1

 Attachments: 4916.txt, data.zip


 Currently seeing nodes throw an EOF while reading a saved cache on the system 
 schema when starting cassandra
  WARN 14:25:54,896 error reading saved cache 
 /ssd/saved_caches/system-schema_columns-KeyCache-b.db
 java.io.EOFException
   at java.io.DataInputStream.readInt(DataInputStream.java:392)
   at 
 org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:349)
   at 
 org.apache.cassandra.service.CacheService$KeyCacheSerializer.deserialize(CacheService.java:378)
   at 
 org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:144)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:278)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:393)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:365)
   at org.apache.cassandra.db.Table.initCf(Table.java:334)
   at org.apache.cassandra.db.Table.init(Table.java:272)
   at org.apache.cassandra.db.Table.open(Table.java:102)
   at org.apache.cassandra.db.Table.open(Table.java:80)
   at org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:320)
   at 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:203)
   at 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:395)
   at 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:438)
 to reproduce delete all data files, start a cluster, leave cluster up long 
 enough to build a cache. nodetool drain, kill cassandra process. start 
 cassandra process in foreground and note EOF thrown (see above for stack 
 trace)

--
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-4916) Starting Cassandra throws EOF while reading saved cache

2013-02-12 Thread Drew Kutcharian (JIRA)

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

Drew Kutcharian updated CASSANDRA-4916:
---

Attachment: data.zip

 Starting Cassandra throws EOF while reading saved cache
 ---

 Key: CASSANDRA-4916
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4916
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Michael Kjellman
Assignee: Dave Brosius
Priority: Minor
 Fix For: 1.2.1

 Attachments: 4916.txt, data.zip


 Currently seeing nodes throw an EOF while reading a saved cache on the system 
 schema when starting cassandra
  WARN 14:25:54,896 error reading saved cache 
 /ssd/saved_caches/system-schema_columns-KeyCache-b.db
 java.io.EOFException
   at java.io.DataInputStream.readInt(DataInputStream.java:392)
   at 
 org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:349)
   at 
 org.apache.cassandra.service.CacheService$KeyCacheSerializer.deserialize(CacheService.java:378)
   at 
 org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:144)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:278)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:393)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:365)
   at org.apache.cassandra.db.Table.initCf(Table.java:334)
   at org.apache.cassandra.db.Table.init(Table.java:272)
   at org.apache.cassandra.db.Table.open(Table.java:102)
   at org.apache.cassandra.db.Table.open(Table.java:80)
   at org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:320)
   at 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:203)
   at 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:395)
   at 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:438)
 to reproduce delete all data files, start a cluster, leave cluster up long 
 enough to build a cache. nodetool drain, kill cassandra process. start 
 cassandra process in foreground and note EOF thrown (see above for stack 
 trace)

--
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-5225) Missing columns, errors when requesting specific columns from wide rows

2013-02-12 Thread Brandon Williams (JIRA)

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

Brandon Williams reassigned CASSANDRA-5225:
---

Assignee: Sylvain Lebresne

 Missing columns, errors when requesting specific columns from wide rows
 ---

 Key: CASSANDRA-5225
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5225
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1
Reporter: Tyler Hobbs
Assignee: Sylvain Lebresne
Priority: Critical
 Fix For: 1.2.2

 Attachments: 5225.txt, pycassa-repro.py


 With Cassandra 1.2.1 (and probably 1.2.0), I'm seeing some problems with 
 Thrift queries that request a set of specific column names when the row is 
 very wide.
 To reproduce, I'm inserting 10 million columns into a single row and then 
 randomly requesting three columns by name in a loop.  It's common for only 
 one or two of the three columns to be returned.  I'm also seeing stack traces 
 like the following in the Cassandra log:
 {noformat}
 ERROR 13:12:01,017 Exception in thread Thread[ReadStage:76,5,main]
 java.lang.RuntimeException: 
 org.apache.cassandra.io.sstable.CorruptSSTableException: 
 org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid 
 column name length 0 
 (/var/lib/cassandra/data/Keyspace1/CF1/Keyspace1-CF1-ib-5-Data.db, 14035168 
 bytes remaining)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1576)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: 
 org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid 
 column name length 0 
 (/var/lib/cassandra/data/Keyspace1/CF1/Keyspace1-CF1-ib-5-Data.db, 14035168 
 bytes remaining)
   at 
 org.apache.cassandra.db.columniterator.SSTableNamesIterator.init(SSTableNamesIterator.java:69)
   at 
 org.apache.cassandra.db.filter.NamesQueryFilter.getSSTableColumnIterator(NamesQueryFilter.java:81)
   at 
 org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:68)
   at 
 org.apache.cassandra.db.CollationController.collectTimeOrderedData(CollationController.java:133)
   at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:65)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1358)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1215)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1127)
   at org.apache.cassandra.db.Table.getRow(Table.java:355)
   at 
 org.apache.cassandra.db.SliceByNamesReadCommand.getRow(SliceByNamesReadCommand.java:64)
   at 
 org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1052)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1572)
   ... 3 more
 {noformat}
 This doesn't seem to happen when the row is smaller, so it might have 
 something to do with incremental large row compaction.

--
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-5225) Missing columns, errors when requesting specific columns from wide rows

2013-02-12 Thread Brandon Williams (JIRA)

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

Brandon Williams commented on CASSANDRA-5225:
-

+1

 Missing columns, errors when requesting specific columns from wide rows
 ---

 Key: CASSANDRA-5225
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5225
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1
Reporter: Tyler Hobbs
Assignee: Sylvain Lebresne
Priority: Critical
 Fix For: 1.2.2

 Attachments: 5225.txt, pycassa-repro.py


 With Cassandra 1.2.1 (and probably 1.2.0), I'm seeing some problems with 
 Thrift queries that request a set of specific column names when the row is 
 very wide.
 To reproduce, I'm inserting 10 million columns into a single row and then 
 randomly requesting three columns by name in a loop.  It's common for only 
 one or two of the three columns to be returned.  I'm also seeing stack traces 
 like the following in the Cassandra log:
 {noformat}
 ERROR 13:12:01,017 Exception in thread Thread[ReadStage:76,5,main]
 java.lang.RuntimeException: 
 org.apache.cassandra.io.sstable.CorruptSSTableException: 
 org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid 
 column name length 0 
 (/var/lib/cassandra/data/Keyspace1/CF1/Keyspace1-CF1-ib-5-Data.db, 14035168 
 bytes remaining)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1576)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: 
 org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid 
 column name length 0 
 (/var/lib/cassandra/data/Keyspace1/CF1/Keyspace1-CF1-ib-5-Data.db, 14035168 
 bytes remaining)
   at 
 org.apache.cassandra.db.columniterator.SSTableNamesIterator.init(SSTableNamesIterator.java:69)
   at 
 org.apache.cassandra.db.filter.NamesQueryFilter.getSSTableColumnIterator(NamesQueryFilter.java:81)
   at 
 org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:68)
   at 
 org.apache.cassandra.db.CollationController.collectTimeOrderedData(CollationController.java:133)
   at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:65)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1358)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1215)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1127)
   at org.apache.cassandra.db.Table.getRow(Table.java:355)
   at 
 org.apache.cassandra.db.SliceByNamesReadCommand.getRow(SliceByNamesReadCommand.java:64)
   at 
 org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1052)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1572)
   ... 3 more
 {noformat}
 This doesn't seem to happen when the row is smaller, so it might have 
 something to do with incremental large row compaction.

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


[Cassandra Wiki] Trivial Update of Lonbdj066 by Lonbdj066

2013-02-12 Thread Apache Wiki
Dear Wiki user,

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

The Lonbdj066 page has been changed by Lonbdj066:
http://wiki.apache.org/cassandra/Lonbdj066

New page:
Wassp People !! The name is LEONE PHILLIPS. I am from Tulsa.BR
BR
I am turning 60. I might take night schooling in The Chilly Military School 
built at St. Louis. One day i would want to do Composing Music. My papa name is 
Timothy  and he is a Computer programmer. My mummy is a Manual Therapist.BR
BR
Also visit my webpage :: [[http://www.shoesashlen.com|christian louboutin sale]]


[Cassandra Wiki] Trivial Update of GlennMore by GlennMore

2013-02-12 Thread Apache Wiki
Dear Wiki user,

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

The GlennMore page has been changed by GlennMore:
http://wiki.apache.org/cassandra/GlennMore?action=diffrev1=4rev2=5

- Yo guys !! The name is OLENE HILL. This feb i will be 40.BR
- I also like to Artwork. My papa name is Ryan and he is a Lifeguard. My mother 
is a Engine-driver.BR
+ Yo bros !! The name is KIMIKO CASEY. I am turning 35.BR
+ I also like to Bell Ringing. My dad name is Chad  and he is a Corporate 
Executive Officer. My momy is a Footman.BR
  BR
- my blog post [[http://www.fairchanelstore.com|chanel wallet]]
+ Also visit my homepage [[http://www.shoesashlen.com|christian louboutin 
outlet]]