svn commit: r1091922 - in /cassandra/branches/cassandra-0.6: build.xml debian/changelog
Author: eevans Date: Wed Apr 13 21:13:43 2011 New Revision: 1091922 URL: http://svn.apache.org/viewvc?rev=1091922&view=rev Log: versioning update for 6.13 point release Modified: cassandra/branches/cassandra-0.6/build.xml cassandra/branches/cassandra-0.6/debian/changelog Modified: cassandra/branches/cassandra-0.6/build.xml URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/build.xml?rev=1091922&r1=1091921&r2=1091922&view=diff == --- cassandra/branches/cassandra-0.6/build.xml (original) +++ cassandra/branches/cassandra-0.6/build.xml Wed Apr 13 21:13:43 2011 @@ -42,7 +42,7 @@ - + http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/debian/changelog?rev=1091922&r1=1091921&r2=1091922&view=diff == --- cassandra/branches/cassandra-0.6/debian/changelog (original) +++ cassandra/branches/cassandra-0.6/debian/changelog Wed Apr 13 21:13:43 2011 @@ -1,3 +1,9 @@ +cassandra (0.6.13) unstable; urgency=low + + * New stable point release. + + -- Eric Evans Wed, 13 Apr 2011 16:11:19 -0500 + cassandra (0.6.12) unstable; urgency=low * New stable point release.
[jira] [Updated] (CASSANDRA-2088) Clean up after failed (repair) streaming operation
[ https://issues.apache.org/jira/browse/CASSANDRA-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2088: -- Reviewer: jbellis Description: (was: From separate reports, compaction and repair are currently missing opportunities to clean up tmp files after failures.) Priority: Minor (was: Major) Fix Version/s: (was: 0.8) 0.7.5 Assignee: Sylvain Lebresne (was: Aaron Morton) Summary: Clean up after failed (repair) streaming operation (was: Temp files for failed compactions/streaming not cleaned up) Created CASSANDRA-2468 for compaction cleanup. Will close this one for streaming. > Clean up after failed (repair) streaming operation > -- > > Key: CASSANDRA-2088 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2088 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Stu Hood >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 0.7.5 > > Attachments: > 0001-Better-detect-failures-from-the-other-side-in-Incomi.patch, > 0001-detect-streaming-failures-and-cleanup-temp-files.patch, > 0002-delete-partial-sstable-if-compaction-error.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2468) Clean up after failed compaction
Clean up after failed compaction Key: CASSANDRA-2468 URL: https://issues.apache.org/jira/browse/CASSANDRA-2468 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jonathan Ellis Assignee: Aaron Morton Priority: Minor Fix For: 0.8 (Started in CASSANDRA-2088.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "HowToCommit" by StuHood
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "HowToCommit" page has been changed by StuHood. http://wiki.apache.org/cassandra/HowToCommit?action=diff&rev1=2&rev2=3 -- 1. Include the Jira issue id in the commit message, along with a short description of the change and the name of the contributor if it is not you. Be sure to get the issue id right, as this causes Jira to link to the change in Subversion (use the issue's "All" tab to see these). 1. Resolve the issue as fixed, thanking the contributor. Always set the "Fix Version" at this point, but please only set a single fix version, the earliest release in which the change will appear. + == Committers == + + The current Committers are [[Committers|listed in the wiki]]. +
svn commit: r1091911 - in /cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress: Session.java operations/IndexedRangeSlicer.java util/Operation.java
Author: brandonwilliams
Date: Wed Apr 13 20:36:41 2011
New Revision: 1091911
URL: http://svn.apache.org/viewvc?rev=1091911&view=rev
Log:
Use old value generation behavior by default in stress.java to allow
indexed range slices to work.
Patch by Pavel Yaskevich, reviewed by brandonwilliams for CASSANDRA-2326
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/util/Operation.java
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java?rev=1091911&r1=1091910&r2=1091911&view=diff
==
---
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
(original)
+++
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
Wed Apr 13 20:36:41 2011
@@ -72,6 +72,7 @@ public class Session
availableOptions.addOption("x", "create-index", true, "Type
of index to create on needed column families (KEYS)");
availableOptions.addOption("R", "replication-strategy", true,
"Replication strategy to use (only on insert if keyspace does not exist),
default:org.apache.cassandra.locator.SimpleStrategy");
availableOptions.addOption("O", "strategy-properties", true,
"Replication strategy properties in the following format
:,:,...");
+availableOptions.addOption("V", "average-size-values", false,
"Generate column values of average rather than specific size");
}
private int numKeys = 1000 * 1000;
@@ -101,6 +102,7 @@ public class Session
private String replicationStrategy =
"org.apache.cassandra.locator.SimpleStrategy";
private Map replicationStrategyOptions = new
HashMap();
+public final boolean averageSizeValues;
// required by Gaussian distribution.
protected int mean;
@@ -247,6 +249,8 @@ public class Session
replicationStrategyOptions.put(keyAndValue[0],
keyAndValue[1]);
}
}
+
+averageSizeValues = cmd.hasOption("V");
}
catch (ParseException e)
{
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java?rev=1091911&r1=1091910&r2=1091911&view=diff
==
---
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java
(original)
+++
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java
Wed Apr 13 20:36:41 2011
@@ -48,8 +48,8 @@ public class IndexedRangeSlicer extends
int received = 0;
-String startOffset = "0";
-ByteBuffer value = values.get(index % values.size());
+String startOffset = String.format(format, 0);
+ByteBuffer value = values.get(1); // only C1 column is indexed
IndexExpression expression = new IndexExpression(columnName,
IndexOperator.EQ, value);
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/util/Operation.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/util/Operation.java?rev=1091911&r1=1091910&r2=1091911&view=diff
==
---
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/util/Operation.java
(original)
+++
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/util/Operation.java
Wed Apr 13 20:36:41 2011
@@ -55,11 +55,33 @@ public abstract class Operation
// Utility methods
+protected List generateValues()
+{
+if (session.averageSizeValues)
+{
+return generateRandomizedValues();
+}
+
+List values = new ArrayList();
+
+for (int i = 0; i < session.getCardinality(); i++)
+{
+String hash = getMD5(Integer.toString(i));
+int times = session.getColumnSize() / hash.length();
+int sumReminder = session.getColumnSize() % hash.length();
+
+String value = new StringBuilder(multiplyString(hash,
times)).append
[jira] [Commented] (CASSANDRA-2467) key validator not getting set when adding a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019504#comment-13019504 ] Gary Dusbabek commented on CASSANDRA-2467: -- todo: we could use a system test to verify that non-default CF and KS options are actually applied. > key validator not getting set when adding a keyspace > > > Key: CASSANDRA-2467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2467 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.8 > > Attachments: > v1-0001-set-requested-key-validator-when-creating-a-keyspace.txt > > > needs to be applied CassandraServer.convertToCFMetaData() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2467) key validator not getting set when adding a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2467: - Attachment: v1-0001-set-requested-key-validator-when-creating-a-keyspace.txt > key validator not getting set when adding a keyspace > > > Key: CASSANDRA-2467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2467 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.8 > > Attachments: > v1-0001-set-requested-key-validator-when-creating-a-keyspace.txt > > > needs to be applied CassandraServer.convertToCFMetaData() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2467) key validator not getting set when adding a keyspace
key validator not getting set when adding a keyspace Key: CASSANDRA-2467 URL: https://issues.apache.org/jira/browse/CASSANDRA-2467 Project: Cassandra Issue Type: Bug Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 needs to be applied CassandraServer.convertToCFMetaData() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2466) bloom filters should avoid huge array allocations to avoid fragmentation concerns
[ https://issues.apache.org/jira/browse/CASSANDRA-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019491#comment-13019491 ] Peter Schuller commented on CASSANDRA-2466: --- Yes, it's not decreasing the total amount. The idea is that with small values, at least you're now left with a tweakable situation where a suitable heap size and a suitable initial occupancy trigger should be sufficient to avoid concurrent mode failures, as long as you're avoiding the fragmentation induced promotion failures (pragmatically, even if theoretically unclean, one can also help CMS along by inserting some minor application level pauses during allocations of many chunks as part of a larger allocation). But the memory pressure remains. Regarding off-heap: I didn't suggest it because I'd personally like to avoid JNI/JNA if possible for "safety" reasons, and I would also like to avoid adding further dependencies on CMS sweeps for external resources (files, off-heap mem, etc) for the usual reasons. But maybe I'm more paranoid about that than most. It would be really nice to just have an explicitly managed pool of fixed-size off-heap buffers of a reasonable size (say, a meg a piece, mmap():ed). I'm thinking maybe the bloom filters can be explicitly managed more easily than the mmaps/brafs for data reading; for example by accepting that for the few requests that race with the removal of an sstable, the bloom filter would just pretend all bits are set. Hmmm... > bloom filters should avoid huge array allocations to avoid fragmentation > concerns > - > > Key: CASSANDRA-2466 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2466 > Project: Cassandra > Issue Type: Bug >Reporter: Peter Schuller >Priority: Minor > > The fact that bloom filters are backed by single large arrays of longs is > expected to interact badly with promotion of objects into old gen with CMS, > due to fragmentation concerns (as discussed in CASSANDRA-2463). > It should be less of an issue than CASSANDRA-2463 in the sense that you need > to have a lot of rows before the array sizes become truly huge. For > comparison, the ~ 143 million row key limit implied by the use of 'int' in > BitSet prior to the switch to OpenBitSet translates roughly to 238 MB > (assuming the limitation factor there was the addressability of the bits with > a 32 bit int, which is my understanding). > Having a preliminary look at OpenBitSet with an eye towards replacing the > single long[] with multiple arrays, it seems that if we're willing to drop > some of the functionality that is not used for bloom filter purposes, the > bits[i] indexing should be pretty easy to augment with modulo to address an > appropriate smaller array. Locality is not an issue since the bloom filter > case is the worst possible case for locality anyway, and it doesn't matter > whether it's one huge array or a number of ~ 64k arrays. > Callers may be affected like BloomFilterSerializer which cares about the > underlying bit array. > If the full functionality of OpenBitSet is to be maintained (e.g., xorCount) > some additional acrobatics would be necessary and presumably at a noticable > performance cost if such operations were to be used in performance critical > places. > An argument against touching OpenBitSet is that it seems to be pretty > carefully written and tested and has some non-trivial details and people have > seemingly benchmarked it quite carefully. On the other hand, the improvement > would then apply to other things as well, such as the bitsets used to keep > track of in-core pages (off the cuff for scale, a 64 gig sstable should imply > a 2 mb bit set, with one bit per 4k page). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1091886 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/io/sstable/
Author: goffinet Date: Wed Apr 13 18:49:40 2011 New Revision: 1091886 URL: http://svn.apache.org/viewvc?rev=1091886&view=rev Log: Merge from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Apr 13 18:49:40 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7:1026516-1091087,1091503,1091542 +/cassandra/branches/cassandra-0.7:1026516-1091087,1091503,1091542,1091654 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090935-1091782 +/cassandra/branches/cassandra-0.8:1090935-1091782,1091884 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3:774578-796573 /incubator/cassandra/branches/cassandra-0.4:810145-834239,834349-834350 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1091886&r1=1091885&r2=1091886&view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Wed Apr 13 18:49:40 2011 @@ -52,6 +52,7 @@ * convert mmap assertion to if/throw so scrub can catch it (CASSANDRA-2417) * Try harder to close files after compaction (CASSANDRA-2431) * re-set bootstrapped flag after move finishes (CASSANDRA-2435) + * use 64KB flush buffer instead of in_memory_compaction_limit (CASSANDRA-2463) 0.7.4 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Apr 13 18:49:40 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 -/cassandra/branches/cassandra-0.7/contrib:1026516-1091087,1091503,1091542 +/cassandra/branches/cassandra-0.7/contrib:1026516-1091087,1091503,1091542,1091654 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090935-1091782 +/cassandra/branches/cassandra-0.8/contrib:1090935-1091782,1091884 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/contrib:774578-796573 /incubator/cassandra/branches/cassandra-0.4/contrib:810145-810987,810994-834239,834349-834350 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Apr 13 18:49:40 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1091087,1091503,1091542 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1091087,1091503,1091542,1091654 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090935-1091782 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090935-1091782,1091884 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/interface/gen-java/org/apache/cassandra/service/Cassandra.java:774578-796573 /incubator/cassandra/branches/cassandra-0.4/interface/gen-java/org/apache/cassandra/service/Cassandra.java:810145-834239,834349-834350 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Apr 13 18:49:40 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface
svn commit: r1091884 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/io/sstable/
Author: goffinet Date: Wed Apr 13 18:49:01 2011 New Revision: 1091884 URL: http://svn.apache.org/viewvc?rev=1091884&view=rev Log: Merge from 0.7 Modified: cassandra/branches/cassandra-0.8/ (props changed) cassandra/branches/cassandra-0.8/CHANGES.txt cassandra/branches/cassandra-0.8/contrib/ (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java Propchange: cassandra/branches/cassandra-0.8/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Apr 13 18:49:01 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7:1026516-1091087,1091503,1091542 +/cassandra/branches/cassandra-0.7:1026516-1091087,1091503,1091542,1091654 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /cassandra/trunk:1090978-1090979 Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1091884&r1=1091883&r2=1091884&view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Wed Apr 13 18:49:01 2011 @@ -52,6 +52,7 @@ * convert mmap assertion to if/throw so scrub can catch it (CASSANDRA-2417) * Try harder to close files after compaction (CASSANDRA-2431) * re-set bootstrapped flag after move finishes (CASSANDRA-2435) + * use 64KB flush buffer instead of in_memory_compaction_limit (CASSANDRA-2463) 0.7.4 Propchange: cassandra/branches/cassandra-0.8/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Apr 13 18:49:01 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 -/cassandra/branches/cassandra-0.7/contrib:1026516-1091087,1091503,1091542 +/cassandra/branches/cassandra-0.7/contrib:1026516-1091087,1091503,1091542,1091654 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /cassandra/trunk/contrib:1090978-1090979 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Apr 13 18:49:01 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1091087,1091503,1091542 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1091087,1091503,1091542,1091654 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 /cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090978-1090979 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Apr 13 18:49:01 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1091087,1091503,1091542 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1091087,1091503,1091542,1091654 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift
[jira] [Updated] (CASSANDRA-2464) Distributed test for read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stu Hood updated CASSANDRA-2464: Attachment: (was: 0001-Distributed-test-for-read-repair.txt) > Distributed test for read repair > > > Key: CASSANDRA-2464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2464 > Project: Cassandra > Issue Type: Test >Reporter: Stu Hood >Assignee: Stu Hood > Labels: test > Fix For: 0.8 > > Attachments: 0001-Distributed-test-for-read-repair.txt > > > See title. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2464) Distributed test for read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stu Hood updated CASSANDRA-2464: Attachment: 0001-Distributed-test-for-read-repair.txt > Distributed test for read repair > > > Key: CASSANDRA-2464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2464 > Project: Cassandra > Issue Type: Test >Reporter: Stu Hood >Assignee: Stu Hood > Labels: test > Fix For: 0.8 > > Attachments: 0001-Distributed-test-for-read-repair.txt > > > See title. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2466) bloom filters should avoid huge array allocations to avoid fragmentation concerns
[ https://issues.apache.org/jira/browse/CASSANDRA-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019457#comment-13019457 ] Ryan King commented on CASSANDRA-2466: -- Moving to smaller arrays would make the allocation easier, but wouldn't reduce the raw amount of memory needed for a large bloom filter. Would it be worth moving these off-heap completely? > bloom filters should avoid huge array allocations to avoid fragmentation > concerns > - > > Key: CASSANDRA-2466 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2466 > Project: Cassandra > Issue Type: Bug >Reporter: Peter Schuller >Priority: Minor > > The fact that bloom filters are backed by single large arrays of longs is > expected to interact badly with promotion of objects into old gen with CMS, > due to fragmentation concerns (as discussed in CASSANDRA-2463). > It should be less of an issue than CASSANDRA-2463 in the sense that you need > to have a lot of rows before the array sizes become truly huge. For > comparison, the ~ 143 million row key limit implied by the use of 'int' in > BitSet prior to the switch to OpenBitSet translates roughly to 238 MB > (assuming the limitation factor there was the addressability of the bits with > a 32 bit int, which is my understanding). > Having a preliminary look at OpenBitSet with an eye towards replacing the > single long[] with multiple arrays, it seems that if we're willing to drop > some of the functionality that is not used for bloom filter purposes, the > bits[i] indexing should be pretty easy to augment with modulo to address an > appropriate smaller array. Locality is not an issue since the bloom filter > case is the worst possible case for locality anyway, and it doesn't matter > whether it's one huge array or a number of ~ 64k arrays. > Callers may be affected like BloomFilterSerializer which cares about the > underlying bit array. > If the full functionality of OpenBitSet is to be maintained (e.g., xorCount) > some additional acrobatics would be necessary and presumably at a noticable > performance cost if such operations were to be used in performance critical > places. > An argument against touching OpenBitSet is that it seems to be pretty > carefully written and tested and has some non-trivial details and people have > seemingly benchmarked it quite carefully. On the other hand, the improvement > would then apply to other things as well, such as the bitsets used to keep > track of in-core pages (off the cuff for scale, a 64 gig sstable should imply > a 2 mb bit set, with one bit per 4k page). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1091857 - /cassandra/branches/cassandra-0.7/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
Author: brandonwilliams
Date: Wed Apr 13 17:42:15 2011
New Revision: 1091857
URL: http://svn.apache.org/viewvc?rev=1091857&view=rev
Log:
Allow pig to use multiple schemas, fix BytesTypes cast during storage.
Patch by Jeremy Hanna, reviewed by brandonwilliams for CASSANDRA-2465
Modified:
cassandra/branches/cassandra-0.7/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
Modified:
cassandra/branches/cassandra-0.7/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java?rev=1091857&r1=1091856&r2=1091857&view=diff
==
---
cassandra/branches/cassandra-0.7/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
(original)
+++
cassandra/branches/cassandra-0.7/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
Wed Apr 13 17:42:15 2011
@@ -68,7 +68,7 @@ public class CassandraStorage extends Lo
public final static String PIG_INITIAL_ADDRESS = "PIG_INITIAL_ADDRESS";
public final static String PIG_PARTITIONER = "PIG_PARTITIONER";
-private static String UDFCONTEXT_SCHEMA_KEY = "cassandra.schema";
+private static String UDFCONTEXT_SCHEMA_KEY_PREFIX = "cassandra.schema";
private final static ByteBuffer BOUND = ByteBufferUtil.EMPTY_BYTE_BUFFER;
private static final Log logger =
LogFactory.getLog(CassandraStorage.class);
@@ -169,7 +169,7 @@ public class CassandraStorage extends Lo
{
UDFContext context = UDFContext.getUDFContext();
Properties property = context.getUDFProperties(CassandraStorage.class);
-return cfdefFromString(property.getProperty(UDFCONTEXT_SCHEMA_KEY));
+return cfdefFromString(property.getProperty(getSchemaContextKey()));
}
private List getDefaultMarshallers(CfDef cfDef) throws
IOException
@@ -226,7 +226,7 @@ public class CassandraStorage extends Lo
this.reader = reader;
}
- private void setLocationFromUri(String location) throws IOException
+private void setLocationFromUri(String location) throws IOException
{
// parse uri into keyspace and columnfamily
String names[];
@@ -396,7 +396,7 @@ public class CassandraStorage extends Lo
if (validators.get(column.name) == null)
// Have to special case BytesType to convert
DataByteArray into ByteBuffer
if (marshallers.get(1) instanceof BytesType)
- column.value = ByteBuffer.wrap(((DataByteArray)
pair.get(1)).get());
+ column.value = objToBB(pair.get(1));
else
column.value =
marshallers.get(1).decompose(pair.get(1));
else
@@ -446,9 +446,10 @@ public class CassandraStorage extends Lo
{
UDFContext context = UDFContext.getUDFContext();
Properties property = context.getUDFProperties(CassandraStorage.class);
-
+
+String schemaContextKey = getSchemaContextKey();
// Only get the schema if we haven't already gotten it
-if (!property.containsKey(UDFCONTEXT_SCHEMA_KEY))
+if (!property.containsKey(schemaContextKey))
{
Cassandra.Client client = null;
try
@@ -466,7 +467,7 @@ public class CassandraStorage extends Lo
break;
}
}
-property.setProperty(UDFCONTEXT_SCHEMA_KEY,
cfdefToString(cfDef));
+property.setProperty(schemaContextKey, cfdefToString(cfDef));
}
catch (TException e)
{
@@ -532,4 +533,14 @@ public class CassandraStorage extends Lo
}
return cfDef;
}
+
+private String getSchemaContextKey()
+{
+StringBuilder sb = new StringBuilder(UDFCONTEXT_SCHEMA_KEY_PREFIX);
+sb.append('.');
+sb.append(keyspace);
+sb.append('.');
+sb.append(column_family);
+return sb.toString();
+}
}
[jira] [Commented] (CASSANDRA-1329) make multiget take a set of keys instead of a list
[ https://issues.apache.org/jira/browse/CASSANDRA-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019443#comment-13019443 ] Jonathan Ellis commented on CASSANDRA-1329: --- Some clients will be fine (pycassa only really cares that it gets an iterable) but you're right, let's leave this alone. > make multiget take a set of keys instead of a list > -- > > Key: CASSANDRA-1329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1329 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Jonathan Ellis >Priority: Minor > Attachments: 1329-rebase.txt, 1329-stresspy-multiget.txt, 1329.txt, > multiget.test, multigetsmall.test > > > this more correctly sets the expectation that the order of keys in that list > doesn't matter, and duplicates don't make sense -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1329) make multiget take a set of keys instead of a list
[ https://issues.apache.org/jira/browse/CASSANDRA-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019440#comment-13019440 ] Ryan King commented on CASSANDRA-1329: -- I don't know if this change is worth the breakage is causes (I assume that all clients will have to be updated). > make multiget take a set of keys instead of a list > -- > > Key: CASSANDRA-1329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1329 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Jonathan Ellis >Priority: Minor > Attachments: 1329-rebase.txt, 1329-stresspy-multiget.txt, 1329.txt, > multiget.test, multigetsmall.test > > > this more correctly sets the expectation that the order of keys in that list > doesn't matter, and duplicates don't make sense -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2460) Make scrub validate deserialized columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019439#comment-13019439 ] Jonathan Ellis commented on CASSANDRA-2460: --- I'd kind of like to push the validation into SSTIdentityIterator, so it gets done in a single place. Is that reasonable? > Make scrub validate deserialized columns > > > Key: CASSANDRA-2460 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2460 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 0.7.5 > > Attachments: 0001-Make-scrub-check-column-fields.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > Right now, scrub deserialize the columns but don't validate the fields, and > such there is a number of errors it could fix (or at least corrupted rows it > could skip) but don't. > This ticket proposes to handle those errors. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2460) Make scrub validate deserialized columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019268#comment-13019268
]
Sylvain Lebresne edited comment on CASSANDRA-2460 at 4/13/11 5:16 PM:
--
Attaching patch against 0.7 branch to validate as much of the column fields I
can think of during scrub.
Note that I didn't do it but it may be worth merging the forceDeserialization
and validateColumns for {Pre|Lazy}CompactedRow.
The 0.8 patch will probably be a little bit different, first because it may be
cleaner to move the validation in CompactionController and because we will need
to handle correctly CounterColumns. I'll write the patch separately when I have
some feedback on this one.
was (Author: slebresne):
Attaching patch against 0.7 branch to validate as much of the column fields
I can think of during scrub.
Note that I didn't do it but it may be worst merging the forceDeserialization
and validateColumns for {Pre|Lazy}CompactedRow.
The 0.8 patch will probably be a little bit different, first because it may be
cleaner to move the validation in CompactionController and because we will need
to handle correctly CounterColumns. I'll write the patch separately when I have
some feedback on this one.
> Make scrub validate deserialized columns
>
>
> Key: CASSANDRA-2460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2460
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 0.7.5
>
> Attachments: 0001-Make-scrub-check-column-fields.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> Right now, scrub deserialize the columns but don't validate the fields, and
> such there is a number of errors it could fix (or at least corrupted rows it
> could skip) but don't.
> This ticket proposes to handle those errors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
[ https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019419#comment-13019419 ] Ed Anuff commented on CASSANDRA-2231: - If you can add the -1, 0, 1 e-o-c suggestion, then I'm good with this. We've been using a preview version of your patch that we put up at https://github.com/riptano/hector-composite to make sure it works. So far it seems to meet every use case, with the exception of the previous questions from April 4 which you correctly pointed out couldn't be solved the way we were suggesting. So, I'm all for getting this out as soon as possible. > Add CompositeType comparer to the comparers provided in > org.apache.cassandra.db.marshal > --- > > Key: CASSANDRA-2231 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2231 > Project: Cassandra > Issue Type: Improvement > Components: Contrib >Affects Versions: 0.7.3 >Reporter: Ed Anuff >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 0.7.5 > > Attachments: CompositeType-and-DynamicCompositeType.patch, > edanuff-CassandraCompositeType-1e253c4.zip > > > CompositeType is a custom comparer that makes it possible to create > comparable composite values out of the basic types that Cassandra currently > supports, such as Long, UUID, etc. This is very useful in both the creation > of custom inverted indexes using columns in a skinny row, where each column > name is a composite value, and also when using Cassandra's built-in secondary > index support, where it can be used to encode the values in the columns that > Cassandra indexes. One scenario for the usage of these is documented here: > http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html. Source for > contribution is attached and has been previously maintained on github here: > https://github.com/edanuff/CassandraCompositeType -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2420) row cache / streaming aren't aware of each other
[ https://issues.apache.org/jira/browse/CASSANDRA-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019400#comment-13019400 ] Sylvain Lebresne commented on CASSANDRA-2420: - bq. I would be more comfortable having LCR throw UnsupportedOperation if asked for full row, since You Shouldn't Do That. Updated patch defines getFullColumnFamily() only for AbstractCompactedRow. However I think it would be a bad idea to fail in the Builder, so the Builder now simply invalidate the cache if he is facing a big row (hence not fitting it in memory) and log a warning since if that happens "you're doing it wrong". I've also changed the switch case in updateCache. > row cache / streaming aren't aware of each other > > > Key: CASSANDRA-2420 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2420 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Matthew F. Dennis >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 0.7.5 > > Attachments: 0001-Handle-the-row-cache-for-streamed-row-v2.patch, > 0001-Handle-the-row-cache-for-streamed-row.patch > > > SSTableWriter.Builder.build() takes tables that resulted from streaming, > repair, bootstrapping, et cetera and builds the indexes and bloom filters > before "adding" it so the current node is aware of it. > However, if there is data present in the cache for a row that is also present > in the streamed table the row cache can over shadow the data in the newly > built table. In other words, until the row in row cache is removed from the > cache (e.g. because it's pushed out because of size, the node is restarted, > the cache is manually cleared) the data in the newly built table will never > be returned to clients. > The solution that seems most reasonable at this point is to have > SSTableWriter.Builder.build() (or something below it) update the row cache if > the row key in the table being built is also present in the cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2420) row cache / streaming aren't aware of each other
[ https://issues.apache.org/jira/browse/CASSANDRA-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2420: Attachment: 0001-Handle-the-row-cache-for-streamed-row-v2.patch > row cache / streaming aren't aware of each other > > > Key: CASSANDRA-2420 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2420 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Matthew F. Dennis >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 0.7.5 > > Attachments: 0001-Handle-the-row-cache-for-streamed-row-v2.patch, > 0001-Handle-the-row-cache-for-streamed-row.patch > > > SSTableWriter.Builder.build() takes tables that resulted from streaming, > repair, bootstrapping, et cetera and builds the indexes and bloom filters > before "adding" it so the current node is aware of it. > However, if there is data present in the cache for a row that is also present > in the streamed table the row cache can over shadow the data in the newly > built table. In other words, until the row in row cache is removed from the > cache (e.g. because it's pushed out because of size, the node is restarted, > the cache is manually cleared) the data in the newly built table will never > be returned to clients. > The solution that seems most reasonable at this point is to have > SSTableWriter.Builder.build() (or something below it) update the row cache if > the row key in the table being built is also present in the cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
[ https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019397#comment-13019397 ] Sylvain Lebresne commented on CASSANDRA-2231: - So I don't know where you guys are with your JPA implementation, but I for one would be keen on getting this out because I do think this is broadly useful. However it is worth making sure this do handle your needs (once this is out, it will be harder to make changes). So how far is this from those needs ? I agree with the change of using -1, 0, 1 for the e-o-c (as this allows 'strictly greater-than' kind of queries; I don't think the attached patch have that already but I'll add the change next time I rebase this, just want to know if there anything else needed first) and you didn't follow up yet on my last comment. Is there something else ? > Add CompositeType comparer to the comparers provided in > org.apache.cassandra.db.marshal > --- > > Key: CASSANDRA-2231 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2231 > Project: Cassandra > Issue Type: Improvement > Components: Contrib >Affects Versions: 0.7.3 >Reporter: Ed Anuff >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 0.7.5 > > Attachments: CompositeType-and-DynamicCompositeType.patch, > edanuff-CassandraCompositeType-1e253c4.zip > > > CompositeType is a custom comparer that makes it possible to create > comparable composite values out of the basic types that Cassandra currently > supports, such as Long, UUID, etc. This is very useful in both the creation > of custom inverted indexes using columns in a skinny row, where each column > name is a composite value, and also when using Cassandra's built-in secondary > index support, where it can be used to encode the values in the columns that > Cassandra indexes. One scenario for the usage of these is documented here: > http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html. Source for > contribution is attached and has been previously maintained on github here: > https://github.com/edanuff/CassandraCompositeType -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1091812 - in /cassandra/branches/cassandra-0.8/drivers/py: cql/errors.py cqlsh
Author: jbellis
Date: Wed Apr 13 15:02:00 2011
New Revision: 1091812
URL: http://svn.apache.org/viewvc?rev=1091812&view=rev
Log:
update cqlsh for python dbapi driver
Modified:
cassandra/branches/cassandra-0.8/drivers/py/cql/errors.py
cassandra/branches/cassandra-0.8/drivers/py/cqlsh
Modified: cassandra/branches/cassandra-0.8/drivers/py/cql/errors.py
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/drivers/py/cql/errors.py?rev=1091812&r1=1091811&r2=1091812&view=diff
==
--- cassandra/branches/cassandra-0.8/drivers/py/cql/errors.py (original)
+++ cassandra/branches/cassandra-0.8/drivers/py/cql/errors.py Wed Apr 13
15:02:00 2011
@@ -15,8 +15,7 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-__all__ = ['InvalidCompressionScheme', 'CQLException', 'InvalidQueryFormat']
+__all__ = ['InvalidCompressionScheme', 'InvalidQueryFormat']
class InvalidCompressionScheme(Exception): pass
class InvalidQueryFormat(Exception): pass
-class CQLException(Exception): pass
Modified: cassandra/branches/cassandra-0.8/drivers/py/cqlsh
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/drivers/py/cqlsh?rev=1091812&r1=1091811&r2=1091812&view=diff
==
--- cassandra/branches/cassandra-0.8/drivers/py/cqlsh (original)
+++ cassandra/branches/cassandra-0.8/drivers/py/cqlsh Wed Apr 13 15:02:00 2011
@@ -26,14 +26,11 @@ import os
import re
try:
-from cql import Connection
-from cql.errors import CQLException
-from cql.results import RowsProxy
+import cql
except ImportError:
sys.path.append(os.path.abspath(os.path.dirname(__file__)))
-from cql import Connection
-from cql.errors import CQLException
-from cql.results import RowsProxy
+import cql
+from cql.results import ResultSet
HISTORY = os.path.join(os.path.expanduser('~'), '.cqlsh')
CQLTYPES = ("bytes", "ascii", "utf8", "timeuuid", "uuid", "long", "int")
@@ -55,10 +52,7 @@ class Shell(cmd.Cmd):
def __init__(self, hostname, port, color=False, username=None,
password=None):
cmd.Cmd.__init__(self)
-self.conn = Connection(hostname,
- port=port,
- username=username,
- password=password)
+self.conn = cql.connect(hostname, port, user=username,
password=password)
if os.path.exists(HISTORY):
readline.read_history_file(HISTORY)
@@ -92,10 +86,11 @@ class Shell(cmd.Cmd):
statement = self.get_statement(arg)
if not statement: return
-result = self.conn.execute(statement)
+cursor = self.conn.cursor()
+cursor.execute(statement)
-if isinstance(result, RowsProxy):
-for row in result:
+if isinstance(cursor.result, ResultSet):
+for row in cursor.result.rows:
self.printout(row.key, BLUE, False)
for column in row.columns:
self.printout(" | ", newline=False)
@@ -105,7 +100,7 @@ class Shell(cmd.Cmd):
self.printout(repr(column.value), YELLOW, False)
self.printout("")
else:
-if result: print result
+if cursor.result: print cursor.result[0]
def emptyline(self):
pass
@@ -221,7 +216,7 @@ if __name__ == '__main__':
except SystemExit:
readline.write_history_file(HISTORY)
break
-except CQLException, cqlerr:
+except cql.Error, cqlerr:
shell.printerr(str(cqlerr), color=RED)
except KeyboardInterrupt:
shell.reset_statement()
[jira] [Updated] (CASSANDRA-2457) Batch_mutate is broken for counters
[ https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2457: Attachment: 0001-Fix-batch_mutate-for-counters.patch Attaching patch against 0.8. Basically this makes SP.mutate() handle a list of mixed RowMutation and CounterMutation (but then each mutation use the right path). This is needed since a batch_mutate() can now mix those. This has an unfortunate consequence however in that I don't think there is a way to distinguish the writeStats of standard insert of the ones of counter insert anymore, and thus this patch remove the latter ones (and count everything in writeStat). > Batch_mutate is broken for counters > --- > > Key: CASSANDRA-2457 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2457 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.8 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 0.8 > > Attachments: 0001-Fix-batch_mutate-for-counters.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > CASSANDRA-2384 allowed for batch_mutate to take counter and non counter > operation, but the code was not updated correctly to handle that case. As it > is, the code will use the first mutation in the batch list to decide whether > to apply the write code path of counter or not, and will thus break if those > are mixed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1091785 - in /cassandra/branches/cassandra-0.8/lib/licenses: guava-r05.txt guava-r08.txt
Author: jbellis Date: Wed Apr 13 14:00:46 2011 New Revision: 1091785 URL: http://svn.apache.org/viewvc?rev=1091785&view=rev Log: update license file for guava Added: cassandra/branches/cassandra-0.8/lib/licenses/guava-r08.txt - copied unchanged from r1091768, cassandra/branches/cassandra-0.8/lib/licenses/guava-r05.txt Removed: cassandra/branches/cassandra-0.8/lib/licenses/guava-r05.txt
svn commit: r1091784 - in /cassandra/trunk: ./ conf/ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ lib/ lib/licenses/ src/java/org/apache/cassandra/cli/ src/java/org/apache/cassandra
Author: jbellis Date: Wed Apr 13 13:59:39 2011 New Revision: 1091784 URL: http://svn.apache.org/viewvc?rev=1091784&view=rev Log: merge from 0.8 Added: cassandra/trunk/lib/jamm-0.2.1.jar - copied unchanged from r1091507, cassandra/branches/cassandra-0.8/lib/jamm-0.2.1.jar cassandra/trunk/lib/licenses/jamm-0.2.1.txt - copied unchanged from r1091507, cassandra/branches/cassandra-0.8/lib/licenses/jamm-0.2.1.txt Removed: cassandra/trunk/lib/jamm-0.2.jar Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/NEWS.txt cassandra/trunk/build.xml cassandra/trunk/conf/cassandra-env.sh cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java cassandra/trunk/src/java/org/apache/cassandra/db/RowIteratorFactory.java cassandra/trunk/src/java/org/apache/cassandra/db/columniterator/IColumnIterator.java cassandra/trunk/src/java/org/apache/cassandra/db/columniterator/SSTableSliceIterator.java cassandra/trunk/src/java/org/apache/cassandra/db/columniterator/SimpleSliceReader.java cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java cassandra/trunk/src/java/org/apache/cassandra/service/StorageServiceMBean.java cassandra/trunk/src/java/org/apache/cassandra/tools/NodeCmd.java cassandra/trunk/src/java/org/apache/cassandra/tools/NodeProbe.java cassandra/trunk/test/distributed/org/apache/cassandra/CountersTest.java cassandra/trunk/test/distributed/org/apache/cassandra/MovementTest.java cassandra/trunk/test/distributed/org/apache/cassandra/MutationTest.java cassandra/trunk/test/distributed/org/apache/cassandra/TestBase.java cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/Session.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Apr 13 13:59:39 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 /cassandra/branches/cassandra-0.7:1026516-1091087,1091503,1091542 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090935-109,1091113,1091148,1091508,1091544 +/cassandra/branches/cassandra-0.8:1090935-1091782 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3:774578-796573 /incubator/cassandra/branches/cassandra-0.4:810145-834239,834349-834350 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1091784&r1=1091783&r2=1091784&view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Wed Apr 13 13:59:39 2011 @@ -18,9 +18,11 @@ * purge tombstones from row cache (CASSANDRA-2305) * push replication_factor into strategy_options (CASSANDRA-1263) * give snapshots the same name on each node (CASSANDRA-1791) + * remove "nodetool loadbalance" (CASSANDRA-2448) * multithreaded compaction (CASSANDRA-2191) * compaction throttling (CASSANDRA-2156) * add key type information and alias (CASSANDRA-2311, 2396) + * cli no longer divides read_repair_chance by 100 (CASSANDRA-2458) 0.7.5 Modified: cassandra/trunk/NEWS.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/NEWS.txt?rev=1091784&r1=1091783&r2=1091784&view=diff == --- cassandra/trunk/NEWS.txt (original) +++ cassandra/trunk/NEWS.txt Wed Apr 13 13:59:39 2011 @@ -1,5 +1,5 @@ -Whatever - +0.8 +=== Upgrading - @@ -10,6 +10,9 @@ Upgrading Upgrading from version 0.7.1 or later can be done with a rolling restart, one node at a time. You do not need to bring down the whole cluster. +The loadbalance command has been removed from nodetool. For similar +behavior, decommission then rebootstrap with empty initial_token. + Other - In the past, sstable2json would write column names and values as hex Modified: cassandra/trunk/build.xml URL: http://svn.apache.org/viewvc/cassandra/trunk/build.xml?rev=1091784&r1=1091783&r2=
[jira] [Commented] (CASSANDRA-1329) make multiget take a set of keys instead of a list
[ https://issues.apache.org/jira/browse/CASSANDRA-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019327#comment-13019327 ] Jake Farrell commented on CASSANDRA-1329: - Just following up on this, committed Thrift-342 which allows PHP to handle using sets of keys rather than a list. If another language does not handle sets correctly within thrift open another ticket for that clients library and i'll have a look at it. > make multiget take a set of keys instead of a list > -- > > Key: CASSANDRA-1329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1329 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Jonathan Ellis >Priority: Minor > Attachments: 1329-rebase.txt, 1329-stresspy-multiget.txt, 1329.txt, > multiget.test, multigetsmall.test > > > this more correctly sets the expectation that the order of keys in that list > doesn't matter, and duplicates don't make sense -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2405) should expose 'time since last successful repair' for easier aes monitoring
[ https://issues.apache.org/jira/browse/CASSANDRA-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019321#comment-13019321 ] Pavel Yaskevich commented on CASSANDRA-2405: It's still around, StorageService, StorageProxy, AntiEntropyService and others live there... > should expose 'time since last successful repair' for easier aes monitoring > --- > > Key: CASSANDRA-2405 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2405 > Project: Cassandra > Issue Type: Improvement >Reporter: Peter Schuller >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.7.5 > > > The practical implementation issues of actually ensuring repair runs is > somewhat of an undocumented/untreated issue. > One hopefully low hanging fruit would be to at least expose the time since > last successful repair for a particular column family, to make it easier to > write a correct script to monitor for lack of repair in a non-buggy fashion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2405) should expose 'time since last successful repair' for easier aes monitoring
[ https://issues.apache.org/jira/browse/CASSANDRA-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019318#comment-13019318 ] Jonathan Ellis commented on CASSANDRA-2405: --- I thought we got rid of .service for 0.7 > should expose 'time since last successful repair' for easier aes monitoring > --- > > Key: CASSANDRA-2405 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2405 > Project: Cassandra > Issue Type: Improvement >Reporter: Peter Schuller >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.7.5 > > > The practical implementation issues of actually ensuring repair runs is > somewhat of an undocumented/untreated issue. > One hopefully low hanging fruit would be to at least expose the time since > last successful repair for a particular column family, to make it easier to > write a correct script to monitor for lack of repair in a non-buggy fashion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2405) should expose 'time since last successful repair' for easier aes monitoring
[ https://issues.apache.org/jira/browse/CASSANDRA-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019313#comment-13019313 ] Pavel Yaskevich commented on CASSANDRA-2405: I will put in under o.a.c.service instead... > should expose 'time since last successful repair' for easier aes monitoring > --- > > Key: CASSANDRA-2405 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2405 > Project: Cassandra > Issue Type: Improvement >Reporter: Peter Schuller >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.7.5 > > > The practical implementation issues of actually ensuring repair runs is > somewhat of an undocumented/untreated issue. > One hopefully low hanging fruit would be to at least expose the time since > last successful repair for a particular column family, to make it easier to > write a correct script to monitor for lack of repair in a non-buggy fashion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2406) Secondary index and index expression problems
[ https://issues.apache.org/jira/browse/CASSANDRA-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-2406: --- Attachment: CASSANDRA-2406.patch > Secondary index and index expression problems > - > > Key: CASSANDRA-2406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2406 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 > Environment: CentOS 5.5 (64bit), JDK 1.6.0_23 >Reporter: Muga Nishizawa >Assignee: Pavel Yaskevich > Fix For: 0.7.5 > > Attachments: CASSANDRA-2406-debug.patch, CASSANDRA-2406.patch, > create_table.cli, node-1.system.log, secondary_index_checkv2.py, > secondary_index_insertv2.py > > > When I iteratively get data with secondary index and index clause, result of > data acquired by consistency level "one" is different from the one by > consistency level "quorum". The one by consistecy level "one" is correct > result. But the one by consistecy level "quorum" is incorrect and is dropped > by Cassandra. > You can reproduce the bug by executing attached programs. > - 1. Start Cassandra cluster. It consists of 3 cassandra nodes and > distributes data by ByteOrderedPartitioner. Initial tokens of those nodes > are ["31", "32", "33"]. > - 2. Create keyspace and column family, according to "create_table.cli", > - 3. Execute "secondary_index_insertv2.py", inserting a few hundred columns > to cluster > - 4. Execute "secondary_index_checkv2.py" and get data with secondary index > and index clause iteratively. "secondary_index_insertv2.py" and > "secondary_index_checkv2.py" require pycassa. > You will be able to execute 4th "secondary_index_checkv2.py" script with > following option so that > you get data with consistency level "one". > % python "secondary_index_checkv2.py" -one > On the other hand, to acquire data with consistency level "quorum", you will > need to use following option. > % python "secondary_index_checkv2.py" -quorum > You can check that result of data acquired by consistency level "one" is > different from one by consistency level "quorum". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2461) LongCompactionSpeedTest fails
[
https://issues.apache.org/jira/browse/CASSANDRA-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2461:
Attachment: 0001-Fix-LongCompactionSpeedTest.patch
That was not updated correctly with CASSANDRA-1938, sorry. Patch attached.
> LongCompactionSpeedTest fails
> -
>
> Key: CASSANDRA-2461
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2461
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.8
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
> Fix For: 0.8
>
> Attachments: 0001-Fix-LongCompactionSpeedTest.patch
>
>
> ant long-test -Dtest.name=LongCompactionSpeedTest fails.
> There are several errors. Here is the first:
> {noformat}
> [junit] java.lang.IllegalArgumentException
> [junit] at java.nio.ByteBuffer.allocate(ByteBuffer.java:311)
> [junit] at
> org.apache.cassandra.db.context.CounterContext.clearAllDelta(CounterContext.java:444)
> [junit] at
> org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:100)
> [junit] at
> org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:36)
> [junit] at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.next(SSTableIdentityIterator.java:158)
> [junit] at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.next(SSTableIdentityIterator.java:41)
> [junit] at
> org.apache.commons.collections.iterators.CollatingIterator.set(CollatingIterator.java:284)
> [junit] at
> org.apache.commons.collections.iterators.CollatingIterator.least(CollatingIterator.java:326)
> [junit] at
> org.apache.commons.collections.iterators.CollatingIterator.next(CollatingIterator.java:230)
> [junit] at
> org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:69)
> [junit] at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
> [junit] at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
> [junit] at
> com.google.common.collect.Iterators$7.computeNext(Iterators.java:614)
> [junit] at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
> [junit] at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
> [junit] at
> org.apache.cassandra.db.ColumnIndexer.serializeInternal(ColumnIndexer.java:76)
> [junit] at
> org.apache.cassandra.db.ColumnIndexer.serialize(ColumnIndexer.java:50)
> [junit] at
> org.apache.cassandra.io.LazilyCompactedRow.(LazilyCompactedRow.java:87)
> [junit] at
> org.apache.cassandra.io.sstable.SSTableWriter$CommutativeRowIndexer.doIndexing(SSTableWriter.java:462)
> [junit] at
> org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364)
> [junit] at
> org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:317)
> [junit] at
> org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1089)
> [junit] at
> org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1080)
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2460) Make scrub validate deserialized columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2460:
Attachment: 0001-Make-scrub-check-column-fields.patch
Attaching patch against 0.7 branch to validate as much of the column fields I
can think of during scrub.
Note that I didn't do it but it may be worst merging the forceDeserialization
and validateColumns for {Pre|Lazy}CompactedRow.
The 0.8 patch will probably be a little bit different, first because it may be
cleaner to move the validation in CompactionController and because we will need
to handle correctly CounterColumns. I'll write the patch separately when I have
some feedback on this one.
> Make scrub validate deserialized columns
>
>
> Key: CASSANDRA-2460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2460
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 0.7.5
>
> Attachments: 0001-Make-scrub-check-column-fields.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> Right now, scrub deserialize the columns but don't validate the fields, and
> such there is a number of errors it could fix (or at least corrupted rows it
> could skip) but don't.
> This ticket proposes to handle those errors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2402) Python dbapi driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019265#comment-13019265 ] Tyler Hobbs commented on CASSANDRA-2402: v3 patch replaces the existing py driver with the dbapi compliant version. 2402-test_cql.txt updates the tests to work with the new driver. > Python dbapi driver for CQL > --- > > Key: CASSANDRA-2402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2402 > Project: Cassandra > Issue Type: Task >Reporter: Jon Hermes >Assignee: Jon Hermes > Fix For: 0.8 > > Attachments: 2402-test_cql.txt, 2402-v3.txt, 2402.txt > > > Create a driver that emulates python's dbapi. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2402) Python dbapi driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs updated CASSANDRA-2402: --- Attachment: 2402-test_cql.txt > Python dbapi driver for CQL > --- > > Key: CASSANDRA-2402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2402 > Project: Cassandra > Issue Type: Task >Reporter: Jon Hermes >Assignee: Jon Hermes > Fix For: 0.8 > > Attachments: 2402-test_cql.txt, 2402-v3.txt, 2402.txt > > > Create a driver that emulates python's dbapi. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2402) Python dbapi driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs updated CASSANDRA-2402: --- Attachment: 2402-v3.txt > Python dbapi driver for CQL > --- > > Key: CASSANDRA-2402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2402 > Project: Cassandra > Issue Type: Task >Reporter: Jon Hermes >Assignee: Jon Hermes > Fix For: 0.8 > > Attachments: 2402-v3.txt, 2402.txt > > > Create a driver that emulates python's dbapi. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2394) Faulty hd kills cluster performance
[ https://issues.apache.org/jira/browse/CASSANDRA-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019251#comment-13019251 ] Thibaut commented on CASSANDRA-2394: In our case, the degredation never stopped. It didn't matter if we connected to the node itself, or another node in the cluster. As soon as we killed the offending node, cluster performance returned to normal again. We also use custom Hector loadbalancing policy (always prefering to connect to the local node), before trying another node. Not sure about what you mean with coordinator nodes? That cluster had 20 nodes, replication level 3. I will look into it more closely when we have a similar problem in the future. > Faulty hd kills cluster performance > --- > > Key: CASSANDRA-2394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2394 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.7.4 >Reporter: Thibaut >Priority: Minor > Fix For: 0.7.5 > > > Hi, > About every week, a node from our main cluster (>100 nodes) has a faulty hd > (Listing the cassandra data storage directoy triggers an input/output error). > Whenever this occurs, I see many timeoutexceptions in our application on > various nodes which cause everything to run very very slowly. Keyrange scans > just timeout and will sometimes never succeed. If I stop cassandra on the > faulty node, everything runs normal again. > It would be great to have some kind of monitoring thread in cassandra which > marks a node as "down" if there are multiple read/write errors to the data > directories. A single faulty hd on 1 node shouldn't affect global cluster > performance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2460) Make scrub validate deserialized columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019247#comment-13019247 ] Sylvain Lebresne commented on CASSANDRA-2460: - Scrub actually deserialize columns just fine, the problem here is that it doesn't validate the fields. Hence it doesn't catch corruption like in CASSANDRA-2373 where a tombstone field is corrupted. This ticket will also run the deserialized names and value through the validators. > Make scrub validate deserialized columns > > > Key: CASSANDRA-2460 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2460 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 0.7.5 > > Original Estimate: 4h > Remaining Estimate: 4h > > Right now, scrub deserialize the columns but don't validate the fields, and > such there is a number of errors it could fix (or at least corrupted rows it > could skip) but don't. > This ticket proposes to handle those errors. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2460) Make scrub validate deserialized columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2460: Description: Right now, scrub deserialize the columns but don't validate the fields, and such there is a number of errors it could fix (or at least corrupted rows it could skip) but don't. This ticket proposes to handle those errors. was: Right now, scrub don't deserialize the columns, and such there is a number of errors it could fix (or at least corrupted rows it could skip) but don't. This ticket proposes to handle those errors. Summary: Make scrub validate deserialized columns (was: Make scrub deserialize rows) > Make scrub validate deserialized columns > > > Key: CASSANDRA-2460 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2460 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 0.7.5 > > Original Estimate: 4h > Remaining Estimate: 4h > > Right now, scrub deserialize the columns but don't validate the fields, and > such there is a number of errors it could fix (or at least corrupted rows it > could skip) but don't. > This ticket proposes to handle those errors. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
