[jira] [Commented] (CASSANDRA-4795) replication, compaction, compression? options are not validated
[ 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
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
[ 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
[ 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
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
Updated Tags: refs/tags/1.1.10-tentative [created] 684994215
[jira] [Commented] (CASSANDRA-5239) Fully Aysnc Server Transport (StorageProxy Layer)
[ 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
[ 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
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
[ 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
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
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
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
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
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
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
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
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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
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
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
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
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
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
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
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
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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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)
[ 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
[ 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
[ 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
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
[ 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
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)
[ 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)
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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.
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
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
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]]