[jira] [Commented] (CASSANDRA-2941) Expose number of rpc timeouts for individual hosts metric via jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095836#comment-13095836 ] Hudson commented on CASSANDRA-2941: --- Integrated in Cassandra-0.8 #310 (See [https://builds.apache.org/job/Cassandra-0.8/310/]) Fix typo introduced by CASSANDRA-2941 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1164068 Files : * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/net/MessagingService.java Expose number of rpc timeouts for individual hosts metric via jmx -- Key: CASSANDRA-2941 URL: https://issues.apache.org/jira/browse/CASSANDRA-2941 Project: Cassandra Issue Type: Improvement Reporter: Melvin Wang Assignee: Melvin Wang Priority: Minor Fix For: 0.8.5 Attachments: c2941-v2.patch We have a total number timeouts for each node. It's better for monitoring to break down this total number into number of timeouts per host that this node tried to connect to. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3115) LongCompactionSpeedTest running longer starting with builds on Aug31
[
https://issues.apache.org/jira/browse/CASSANDRA-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095835#comment-13095835
]
Hudson commented on CASSANDRA-3115:
---
Integrated in Cassandra-0.8 #310 (See
[https://builds.apache.org/job/Cassandra-0.8/310/])
Push BF debug logging to trace to fix LongCompactionSpeedTest timeouts.
Patch by brandonwilliams for CASSANDRA-3115
brandonwilliams :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1164213
Files :
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/utils/BloomFilter.java
LongCompactionSpeedTest running longer starting with builds on Aug31
Key: CASSANDRA-3115
URL: https://issues.apache.org/jira/browse/CASSANDRA-3115
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.5
Environment: Cassandra-0.8 branch, nightly builds.
MacOS and Debian
Reporter: Cathy Daw
Assignee: Brandon Williams
Priority: Minor
The Long tests started consistently timing out as this build of cassandra:
[https://jenkins.qa.datastax.com/job/CassandraLong/131/console]
The regression server shows pretty consistent run times for this test, and
then consistent timeouts from this point forward.
{code}
[junit] Testsuite:
org.apache.cassandra.db.compaction.LongCompactionSpeedTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 111.379 sec
[junit]
[junit] - Standard Output ---
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=1 colsper=20: 1637 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=20 colsper=1: 6144 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=100 rowsper=800 colsper=5: 2379 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=1 colsper=50: 15690 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=50 colsper=1: 20953 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=100 rowsper=1000 colsper=5: 5672 ms
{code}
After increasing the timeout, the run time shows are now:
{code}
[junit] Testsuite:
org.apache.cassandra.db.compaction.LongCompactionSpeedTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 409.486 sec
[junit]
[junit] - Standard Output ---
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=1 colsper=20: 2465 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=20 colsper=1: 29407 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=100 rowsper=800 colsper=5: 2456 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=1 colsper=50: 14588 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=50 colsper=1: 100794 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=100 rowsper=1000 colsper=5: 19266 ms
{code}
*Single node local run: Build 1056 / on Aug 30 / Macbook Pro w/ 8 GB ram
(all apps shutdown)*
{panel}
+Run 1: Fresh install with no log or lib dir+
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=1 colsper=20: 850 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=20 colsper=1: *3004 ms*
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=100 rowsper=800 colsper=5: 767 ms
+Run 2: Invoke test without restarting the server+
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=1 colsper=20: 826 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=20 colsper=1: *3030 ms*
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=100 rowsper=800 colsper=5: 776 ms
+Run 3: Invoke test without restarting the server+
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=1 colsper=20: 830 ms
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=20 colsper=1: *2964 ms*
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=100 rowsper=800 colsper=5: 635 ms
+Run 4: Invoke test without restarting the server+
[junit] org.apache.cassandra.db.compaction.LongCompactionSpeedTest:
sstables=2 rowsper=1 colsper=20: 931 ms
[jira] [Commented] (CASSANDRA-3117) StorageServiceMBean is missing a getCompactionThroughputMbPerSec() method
[ https://issues.apache.org/jira/browse/CASSANDRA-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095837#comment-13095837 ] Hudson commented on CASSANDRA-3117: --- Integrated in Cassandra-0.8 #310 (See [https://builds.apache.org/job/Cassandra-0.8/310/]) add missing mbean method Patch by eevans; reviewed by jbellis for CASSANDRA-3117 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1164127 Files : * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageService.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageServiceMBean.java StorageServiceMBean is missing a getCompactionThroughputMbPerSec() method - Key: CASSANDRA-3117 URL: https://issues.apache.org/jira/browse/CASSANDRA-3117 Project: Cassandra Issue Type: Bug Components: Core, Tools Affects Versions: 0.8.0 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Fix For: 0.8.5 Attachments: v1-0001-CASSANDRA-3117-add-missing-mbean-method.txt Without a getter, you can assign a new value but not query the existing one (which is strange). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3116) Compactions can (seriously )delay schema migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095861#comment-13095861 ] Sylvain Lebresne commented on CASSANDRA-3116: - I think the _raison d'être_ of the lock is because we need to mark all sstables compacted for them to be removed when dropping, but that cannot be done correctly if some sstable are being compacted. But couldn't we just delay the compacted marking ? For instance, we could have a 'isDropped' switch in DataTracker such that when that switch is on the replace() method just remove the 'replacements' sstables. So the drop keyspace/cf would set the isDropped flag first, then grab any sstable files that is not being compacted and mark those right away. It may be a bit tricky to do that atomically but _à priori_ it sounds doable. We'll probably want to add a call to some checkForDropped() method in case a compaction fails to be sure we don't leave sstables behind in that case. Another option may be to just stop the running compactions (CASSANDRA-1740) so that we can mark everything compacted at once. I may be harder to make that thread safe though, not sure, and CASSANDRA-1740 is not in yet. Compactions can (seriously )delay schema migrations --- Key: CASSANDRA-3116 URL: https://issues.apache.org/jira/browse/CASSANDRA-3116 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Reporter: Eric Evans Fix For: 1.1 A compaction lock is acquired when dropping keyspaces or column families which will cause the schema migration to block if a compaction is in progress. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1164399 - in /cassandra/branches/cassandra-0.8: CHANGES.txt NEWS.txt debian/cassandra.install
Author: slebresne Date: Fri Sep 2 08:33:17 2011 New Revision: 1164399 URL: http://svn.apache.org/viewvc?rev=1164399view=rev Log: Bundle sstableloader with the debian package patch by slebresne; reviewed by urandom for CASSANDRA-3113 Modified: cassandra/branches/cassandra-0.8/CHANGES.txt cassandra/branches/cassandra-0.8/NEWS.txt cassandra/branches/cassandra-0.8/debian/cassandra.install Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1164399r1=1164398r2=1164399view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Fri Sep 2 08:33:17 2011 @@ -50,6 +50,7 @@ hanging forever) (CASSANDRA-2433) * fix handling of the empty byte buffer by ReversedType (CASSANDRA-3111) * optionally skip log4j configuration (CASSANDRA-3061) + * bundle sstableloader with the debian package (CASSANDRA-3113) 0.8.4 * include files-to-be-streamed in StreamInSession.getSources (CASSANDRA-2972) Modified: cassandra/branches/cassandra-0.8/NEWS.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/NEWS.txt?rev=1164399r1=1164398r2=1164399view=diff == --- cassandra/branches/cassandra-0.8/NEWS.txt (original) +++ cassandra/branches/cassandra-0.8/NEWS.txt Fri Sep 2 08:33:17 2011 @@ -1,3 +1,11 @@ +0.8.5 += + +Other +- +- The sstableloader is now bundled with the debian package + + 0.8.4 = Modified: cassandra/branches/cassandra-0.8/debian/cassandra.install URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/debian/cassandra.install?rev=1164399r1=1164398r2=1164399view=diff == --- cassandra/branches/cassandra-0.8/debian/cassandra.install (original) +++ cassandra/branches/cassandra-0.8/debian/cassandra.install Fri Sep 2 08:33:17 2011 @@ -9,5 +9,6 @@ bin/nodetool usr/bin bin/json2sstable usr/bin bin/sstable2json usr/bin bin/sstablekeys usr/bin +bin/sstableloader usr/bin lib/*.jar usr/share/cassandra/lib lib/licenses usr/share/doc/cassandra
svn commit: r1164400 - in /cassandra/trunk: ./ contrib/ debian/ interface/thrift/gen-java/org/apache/cassandra/thrift/
Author: slebresne Date: Fri Sep 2 08:34:27 2011 New Revision: 1164400 URL: http://svn.apache.org/viewvc?rev=1164400view=rev Log: merge from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/NEWS.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/debian/cassandra.install 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) Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 08:34:27 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1163782 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1163783,1164068-1164069 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1163783,1164068-1164069,1164399 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1164400r1=1164399r2=1164400view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Fri Sep 2 08:34:27 2011 @@ -106,6 +106,7 @@ * catch invalid key_validation_class before instantiating UpdateColumnFamily (CASSANDRA-3102) * make Range and Bounds objects client-safe (CASSANDRA-3108) * optionally skip log4j configuration (CASSANDRA-3061) + * bundle sstableloader with the debian package (CASSANDRA-3113) 0.8.4 * include files-to-be-streamed in StreamInSession.getSources (CASSANDRA-2972) Modified: cassandra/trunk/NEWS.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/NEWS.txt?rev=1164400r1=1164399r2=1164400view=diff == --- cassandra/trunk/NEWS.txt (original) +++ cassandra/trunk/NEWS.txt Fri Sep 2 08:34:27 2011 @@ -40,6 +40,14 @@ Other created ColumnFamilies. +0.8.5 += + +Other +- +- The sstableloader is now bundled with the debian package + + 0.8.4 = Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 08:34:27 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-1163782 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1163783,1164068-1164069 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1163783,1164068-1164069,1164399 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 Modified: cassandra/trunk/debian/cassandra.install URL: http://svn.apache.org/viewvc/cassandra/trunk/debian/cassandra.install?rev=1164400r1=1164399r2=1164400view=diff == --- cassandra/trunk/debian/cassandra.install (original) +++ cassandra/trunk/debian/cassandra.install Fri Sep 2 08:34:27 2011 @@ -9,5 +9,6 @@ bin/nodetool usr/bin bin/json2sstable usr/bin bin/sstable2json usr/bin bin/sstablekeys usr/bin +bin/sstableloader usr/bin lib/*.jar usr/share/cassandra/lib lib/licenses usr/share/doc/cassandra Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 08:34:27 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-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1163782 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654
[jira] [Created] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Priority: Minor In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Perroud updated CASSANDRA-3122: -- Attachment: SSTableSimpleUnsortedWriter.patch Small patch that merge the smallest CF with the other one instead of always the existing one with the new one. SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Priority: Minor Attachments: SSTableSimpleUnsortedWriter.patch In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3113) Bundle sstableloader with the Debian package
[ https://issues.apache.org/jira/browse/CASSANDRA-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095893#comment-13095893 ] Hudson commented on CASSANDRA-3113: --- Integrated in Cassandra-0.8 #311 (See [https://builds.apache.org/job/Cassandra-0.8/311/]) Bundle sstableloader with the debian package patch by slebresne; reviewed by urandom for CASSANDRA-3113 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1164399 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/NEWS.txt * /cassandra/branches/cassandra-0.8/debian/cassandra.install Bundle sstableloader with the Debian package Key: CASSANDRA-3113 URL: https://issues.apache.org/jira/browse/CASSANDRA-3113 Project: Cassandra Issue Type: Improvement Affects Versions: 0.8.1 Reporter: Joaquin Casares Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8.5 Attachments: 3113.patch Add sstableloader to /usr/bin/ along with the other Cassandra tools. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2610) Have the repair of a range repair *all* the replica for that range
[ https://issues.apache.org/jira/browse/CASSANDRA-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095895#comment-13095895 ] Sylvain Lebresne commented on CASSANDRA-2610: - That last patch lgtm, I'll go ahead and commit. Have the repair of a range repair *all* the replica for that range -- Key: CASSANDRA-2610 URL: https://issues.apache.org/jira/browse/CASSANDRA-2610 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0 Attachments: 0001-Make-repair-repair-all-hosts-v2.patch, 0001-Make-repair-repair-all-hosts.patch, 0002-Cleanup-log-messages-v2.patch, 0003-cleanup-and-fix-private-reference.patch Original Estimate: 8h Remaining Estimate: 8h Say you have a range R whose replica for that range are A, B and C. If you run repair on node A for that range R, when the repair end you only know that A is fully repaired. B and C are not. That is B and C are up to date with A before the repair, but are not up to date with one another. It makes it a pain to schedule optimal cluster repairs, that is repairing a full cluster without doing work twice (because you would have still have to run a repair on B or C, which will make A, B and C redo a validation compaction on R, and with more replica it's even more annoying). However it is fairly easy during the first repair on A to have him compare all the merkle trees, i.e the ones for B and C, and ask to B or C to stream between them whichever the differences they have. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3031) Add 4 byte integer type
[ https://issues.apache.org/jira/browse/CASSANDRA-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-3031: --- Attachment: apache-cassandra-0.8.4-SNAPSHOT.jar 0.8.4 with patch applied. Use it for testing Add 4 byte integer type --- Key: CASSANDRA-3031 URL: https://issues.apache.org/jira/browse/CASSANDRA-3031 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.4 Environment: any Reporter: Radim Kolar Priority: Minor Labels: hector, lhf Fix For: 1.0 Attachments: apache-cassandra-0.8.4-SNAPSHOT.jar, src.diff, test.diff Cassandra currently lacks support for 4byte fixed size integer data type. Java API Hector and C libcassandra likes to serialize integers as 4 bytes in network order. Problem is that you cant use cassandra-cli to manipulate stored rows. Compatibility with other applications using api following cassandra integer encoding standard is problematic too. Because adding new datatype/validator is fairly simple I recommend to add int4 data type. Compatibility with hector is important because it is most used Java cassandra api and lot of applications are using it. This problem was discussed several times already http://comments.gmane.org/gmane.comp.db.hector.user/2125 https://issues.apache.org/jira/browse/CASSANDRA-2585 It would be nice to have compatibility with cassandra-cli and other applications without rewriting hector apps. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1164463 - in /cassandra/trunk: ./ src/java/org/apache/cassandra/net/ src/java/org/apache/cassandra/service/ src/java/org/apache/cassandra/streaming/ src/java/org/apache/cassandra/utils/ t
Author: slebresne
Date: Fri Sep 2 10:24:21 2011
New Revision: 1164463
URL: http://svn.apache.org/viewvc?rev=1164463view=rev
Log:
Make repair of a range sync all replica pairs for this range
patch by slebresne; reviewed by jbellis for CASSANDRA-2610
Added:
cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamingRepairTask.java
Modified:
cassandra/trunk/CHANGES.txt
cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java
cassandra/trunk/src/java/org/apache/cassandra/service/AntiEntropyService.java
cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java
cassandra/trunk/src/java/org/apache/cassandra/utils/UUIDGen.java
cassandra/trunk/test/unit/org/apache/cassandra/io/CompactSerializerTest.java
cassandra/trunk/test/unit/org/apache/cassandra/service/AntiEntropyServiceTestAbstract.java
Modified: cassandra/trunk/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1164463r1=1164462r2=1164463view=diff
==
--- cassandra/trunk/CHANGES.txt (original)
+++ cassandra/trunk/CHANGES.txt Fri Sep 2 10:24:21 2011
@@ -55,6 +55,7 @@
to be down before starting (CASSANDRA-2034)
* Make the compression algorithm and chunk length configurable
(CASSANDRA-3001)
* Add throttling for internode streaming (CASSANDRA-3080)
+ * make the repair of a range repair all replica (CASSANDRA-2610)
0.8.5
* fix NPE when encryption_options is unspecified (CASSANDRA-3007)
Modified:
cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java?rev=1164463r1=1164462r2=1164463view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java Fri
Sep 2 10:24:21 2011
@@ -63,9 +63,11 @@ public final class MessagingService impl
{
public static final String MBEAN_NAME =
org.apache.cassandra.net:type=MessagingService;
+// 8 bits version, so don't waste versions
public static final int VERSION_07 = 1;
public static final int VERSION_080 = 2;
-public static final int version_ = 3; // 8 bits, so don't waste versions
+public static final int VERSION_10 = 3;
+public static final int version_ = VERSION_10;
static SerializerType serializerType_ = SerializerType.BINARY;
Modified:
cassandra/trunk/src/java/org/apache/cassandra/service/AntiEntropyService.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/service/AntiEntropyService.java?rev=1164463r1=1164462r2=1164463view=diff
==
---
cassandra/trunk/src/java/org/apache/cassandra/service/AntiEntropyService.java
(original)
+++
cassandra/trunk/src/java/org/apache/cassandra/service/AntiEntropyService.java
Fri Sep 2 10:24:21 2011
@@ -24,7 +24,6 @@ import java.security.MessageDigest;
import java.util.*;
import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicBoolean;
-import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.Condition;
import com.google.common.base.Objects;
@@ -44,17 +43,13 @@ import org.apache.cassandra.dht.RandomPa
import org.apache.cassandra.dht.Range;
import org.apache.cassandra.gms.*;
import org.apache.cassandra.io.ICompactSerializer;
-import org.apache.cassandra.io.sstable.SSTableReader;
import org.apache.cassandra.io.util.FastByteArrayInputStream;
import org.apache.cassandra.io.util.FastByteArrayOutputStream;
import org.apache.cassandra.net.CompactEndpointSerializationHelper;
import org.apache.cassandra.net.IVerbHandler;
import org.apache.cassandra.net.Message;
import org.apache.cassandra.net.MessagingService;
-import org.apache.cassandra.streaming.OperationType;
-import org.apache.cassandra.streaming.StreamIn;
-import org.apache.cassandra.streaming.StreamOut;
-import org.apache.cassandra.streaming.StreamOutSession;
+import org.apache.cassandra.streaming.*;
import org.apache.cassandra.utils.*;
/**
@@ -130,6 +125,8 @@ public class AntiEntropyService
return futureTask;
}
+// for testing only. Create a session corresponding to a fake request and
+// add it to the sessions (avoid NPE in tests)
RepairFuture submitArtificialRepairSession(TreeRequest req, String
tablename, String... cfnames)
{
RepairFuture futureTask = new RepairSession(req, tablename,
cfnames).getFuture();
@@ -171,6 +168,8 @@ public class AntiEntropyService
RepairSession session = sessions.get(request.sessionid);
assert session != null;
+logger.info(String.format([repair #%s] Received merkle tree for %s
from %s, session.getName(), request.cf.right,
[jira] [Updated] (CASSANDRA-2606) Expose through JMX the ability to repair only the primary range
[ https://issues.apache.org/jira/browse/CASSANDRA-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2606: Reviewer: jbellis Fix Version/s: (was: 0.8.5) 1.0 Expose through JMX the ability to repair only the primary range --- Key: CASSANDRA-2606 URL: https://issues.apache.org/jira/browse/CASSANDRA-2606 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0 Attachments: 0001-Add-JMX-commands-to-repair-primary-range-v2.patch, 0001-Add-JMX-commands-to-repair-primary-range.patch Original Estimate: 2h Remaining Estimate: 2h CASSANDRA-2324 introduces the ability to do a repair only on a given range. This ticket proposes to add a nodetool repairPrimaryRange to trigger the repair of only the primary range of a node. This allows to repair a full cluster without any work duplication (or at least make it much simpler). This also introdude a global_repair command to clustertool to trigger the primary range repair on each node of the cluster one after another (we could do all in parallel, but that's probably not nice on the cluster). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2610) Have the repair of a range repair *all* the replica for that range
[ https://issues.apache.org/jira/browse/CASSANDRA-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-2610. - Resolution: Fixed Reviewer: jbellis Committed, thanks Have the repair of a range repair *all* the replica for that range -- Key: CASSANDRA-2610 URL: https://issues.apache.org/jira/browse/CASSANDRA-2610 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0 Attachments: 0001-Make-repair-repair-all-hosts-v2.patch, 0001-Make-repair-repair-all-hosts.patch, 0002-Cleanup-log-messages-v2.patch, 0003-cleanup-and-fix-private-reference.patch Original Estimate: 8h Remaining Estimate: 8h Say you have a range R whose replica for that range are A, B and C. If you run repair on node A for that range R, when the repair end you only know that A is fully repaired. B and C are not. That is B and C are up to date with A before the repair, but are not up to date with one another. It makes it a pain to schedule optimal cluster repairs, that is repairing a full cluster without doing work twice (because you would have still have to run a repair on B or C, which will make A, B and C redo a validation compaction on R, and with more replica it's even more annoying). However it is fairly easy during the first repair on A to have him compare all the merkle trees, i.e the ones for B and C, and ask to B or C to stream between them whichever the differences they have. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Perroud updated CASSANDRA-3122: -- Attachment: SSTableSimpleUnsortedWriter-v2.patch Version 2 using getEstimatedColumnCount SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Priority: Minor Attachments: SSTableSimpleUnsortedWriter-v2.patch, SSTableSimpleUnsortedWriter.patch In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095913#comment-13095913
]
Pavel Yaskevich commented on CASSANDRA-2474:
bq. We already have the transposition as a visual hint as to what is going
on. I don't think it's difficult to say that you need to use componentX when
using transposition, and :colon tokens are usually used to represent bind
variables in SQL drivers.
I didn't use :transposed keyword any where but I'm file using it instead of
:colon tokens. I don't like componentX notation because we can simply
preserve ordering of the arguments to make the same thing which is much clearer
syntax on my opinion
bq. Maybe it is better if we will support (..,..,..) notation for composite
columns
Can be used as a replacement for componentX
bq. Sorry, I don't follow.
You wrote:
bq. If I wanted to add a location tweet field, I'd need to delete (e.g.) the
2e1c3308,cscotta column and replace it with 2e1c3308,cscotta,location. So,
generally not recommended... but the composite column spec implies we should
support it.) Which brings us to: how to deal with insert/update in composite
columns.
I mean when we want to extend 2e1c3308,cscotta with location we can simply
update old column's name to 2e1c3308,cscotta,location, for querying we can
use 1/0/-1 as 'end-of-component' byte from CompositeType doc when we want
to search by specific components of the column name.
e.g. (if I understand CompositeType annotation correctly)
{noformat}
SELECT name AS (tweet_id, username), value AS body
FROM timeline
WHERE tweet_id = '95a789a' AND user_id = 'cscotta'
{noformat}
start = 795a789a.getBytes()07cscotta.getBytes()0
end = 795a789a.getBytes()07cscotta.getBytes()1
Which should give as *all* columns where column name starts with 95a789a,cscotta
{noformat}
SELECT name AS (tweet_id, username, location), value AS body
FROM timeline
WHERE tweet_id = '95a789a' AND user_id = 'cscotta' AND location = 'USA'
{noformat}
start = 795a789a.getBytes()07cscotta.getBytes()03USA.getBytes()0
end = 795a789a.getBytes()07cscotta.getBytes()13USA.getBytes()1
Which should give as *all* columns where column name starts with
95a789a,cscotta,USA
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: Sub-task
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.0
Attachments: screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2610) Have the repair of a range repair *all* the replica for that range
[ https://issues.apache.org/jira/browse/CASSANDRA-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095916#comment-13095916 ] Hudson commented on CASSANDRA-2610: --- Integrated in Cassandra #1067 (See [https://builds.apache.org/job/Cassandra/1067/]) Make repair of a range sync all replica pairs for this range patch by slebresne; reviewed by jbellis for CASSANDRA-2610 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1164463 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java * /cassandra/trunk/src/java/org/apache/cassandra/service/AntiEntropyService.java * /cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamingRepairTask.java * /cassandra/trunk/src/java/org/apache/cassandra/utils/UUIDGen.java * /cassandra/trunk/test/unit/org/apache/cassandra/io/CompactSerializerTest.java * /cassandra/trunk/test/unit/org/apache/cassandra/service/AntiEntropyServiceTestAbstract.java Have the repair of a range repair *all* the replica for that range -- Key: CASSANDRA-2610 URL: https://issues.apache.org/jira/browse/CASSANDRA-2610 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0 Attachments: 0001-Make-repair-repair-all-hosts-v2.patch, 0001-Make-repair-repair-all-hosts.patch, 0002-Cleanup-log-messages-v2.patch, 0003-cleanup-and-fix-private-reference.patch Original Estimate: 8h Remaining Estimate: 8h Say you have a range R whose replica for that range are A, B and C. If you run repair on node A for that range R, when the repair end you only know that A is fully repaired. B and C are not. That is B and C are up to date with A before the repair, but are not up to date with one another. It makes it a pain to schedule optimal cluster repairs, that is repairing a full cluster without doing work twice (because you would have still have to run a repair on B or C, which will make A, B and C redo a validation compaction on R, and with more replica it's even more annoying). However it is fairly easy during the first repair on A to have him compare all the merkle trees, i.e the ones for B and C, and ask to B or C to stream between them whichever the differences they have. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095913#comment-13095913
]
Pavel Yaskevich edited comment on CASSANDRA-2474 at 9/2/11 11:16 AM:
-
bq. We already have the transposition as a visual hint as to what is going
on. I don't think it's difficult to say that you need to use componentX when
using transposition, and :colon tokens are usually used to represent bind
variables in SQL drivers.
I didn't use :transposed keyword any where but I'm file using it instead of
:colon tokens. I don't like componentX notation because we can simply
preserve ordering of the arguments to make the same thing which is much clearer
syntax on my opinion
bq. Maybe it is better if we will support (..,..,..) notation for composite
columns
Can be used as a replacement for componentX
bq. Sorry, I don't follow.
You wrote:
bq. If I wanted to add a location tweet field, I'd need to delete (e.g.) the
2e1c3308,cscotta column and replace it with 2e1c3308,cscotta,location. So,
generally not recommended... but the composite column spec implies we should
support it.) Which brings us to: how to deal with insert/update in composite
columns.
I mean when we want to extend 2e1c3308,cscotta with location we can simply
update old column's name to 2e1c3308,cscotta,location, for querying we can
use 1/0/-1 as 'end-of-component' byte from CompositeType doc when we want
to search by specific components of the column name.
e.g. (if I understand CompositeType annotation correctly)
{noformat}
SELECT name AS (tweet_id, username), value AS body
FROM timeline
WHERE tweet_id = '95a789a' AND user_id = 'cscotta'
{noformat}
start = 795a789a.getBytes()07cscotta.getBytes()0
end = 795a789a.getBytes()07cscotta.getBytes()1
Which should give as *all* columns where column name starts with 95a789a,cscotta
{noformat}
SELECT name AS (tweet_id, username, location), value AS body
FROM timeline
WHERE tweet_id = '95a789a' AND user_id = 'cscotta' AND location = 'USA'
{noformat}
start = 795a789a.getBytes()07cscotta.getBytes()03USA.getBytes()0
end = 795a789a.getBytes()07cscotta.getBytes()03USA.getBytes()1
Which should give as *all* columns where column name starts with
95a789a,cscotta,USA
was (Author: xedin):
bq. We already have the transposition as a visual hint as to what is
going on. I don't think it's difficult to say that you need to use componentX
when using transposition, and :colon tokens are usually used to represent bind
variables in SQL drivers.
I didn't use :transposed keyword any where but I'm file using it instead of
:colon tokens. I don't like componentX notation because we can simply
preserve ordering of the arguments to make the same thing which is much clearer
syntax on my opinion
bq. Maybe it is better if we will support (..,..,..) notation for composite
columns
Can be used as a replacement for componentX
bq. Sorry, I don't follow.
You wrote:
bq. If I wanted to add a location tweet field, I'd need to delete (e.g.) the
2e1c3308,cscotta column and replace it with 2e1c3308,cscotta,location. So,
generally not recommended... but the composite column spec implies we should
support it.) Which brings us to: how to deal with insert/update in composite
columns.
I mean when we want to extend 2e1c3308,cscotta with location we can simply
update old column's name to 2e1c3308,cscotta,location, for querying we can
use 1/0/-1 as 'end-of-component' byte from CompositeType doc when we want
to search by specific components of the column name.
e.g. (if I understand CompositeType annotation correctly)
{noformat}
SELECT name AS (tweet_id, username), value AS body
FROM timeline
WHERE tweet_id = '95a789a' AND user_id = 'cscotta'
{noformat}
start = 795a789a.getBytes()07cscotta.getBytes()0
end = 795a789a.getBytes()07cscotta.getBytes()1
Which should give as *all* columns where column name starts with 95a789a,cscotta
{noformat}
SELECT name AS (tweet_id, username, location), value AS body
FROM timeline
WHERE tweet_id = '95a789a' AND user_id = 'cscotta' AND location = 'USA'
{noformat}
start = 795a789a.getBytes()07cscotta.getBytes()03USA.getBytes()0
end = 795a789a.getBytes()07cscotta.getBytes()13USA.getBytes()1
Which should give as *all* columns where column name starts with
95a789a,cscotta,USA
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: Sub-task
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.0
Attachments: screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound
[jira] [Updated] (CASSANDRA-3123) Don't try to build secondary indexes when there is none
[ https://issues.apache.org/jira/browse/CASSANDRA-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-3123: Attachment: 3123.patch Attaching patch against 0.8. It makes buildSecondaryIndexes just return if there is no indexed columns. Don't try to build secondary indexes when there is none --- Key: CASSANDRA-3123 URL: https://issues.apache.org/jira/browse/CASSANDRA-3123 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 0.8.5 Attachments: 3123.patch buildSecondaryIndexes() is sometimes called without checking the cfs has secondary indexes. Has a result, it prints a useless message and will trigger a bunch of useless action (among which, a full scan of the indexed column family). This is not a huge problem in 0.8 because only the fairly new loadNewSSTables() call does this (which doesn't mean we should fix it). But in trunk, it does this after every streamIn session. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3118) nodetool can not decommission a node
[ https://issues.apache.org/jira/browse/CASSANDRA-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095936#comment-13095936 ] Jonathan Ellis commented on CASSANDRA-3118: --- No, I cannot reproduce this problem. nodetool can not decommission a node -- Key: CASSANDRA-3118 URL: https://issues.apache.org/jira/browse/CASSANDRA-3118 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.4 Environment: Cassandra0.84 Reporter: deng Fix For: 0.8.5 Attachments: 3118-debug.txt when i use nodetool ring and get the result ,and than i want to decommission 100.86.17.90 node ,but i get the error: [root@ip bin]# ./nodetool -h10.86.12.225 ring Address DC RackStatus State LoadOwns Token 154562542458917734942660802527609328132 100.86.17.90 datacenter1 rack1 Up Leaving 1.08 MB 11.21% 3493450320433654773610109291263389161 100.86.12.225datacenter1 rack1 Up Normal 558.25 MB 14.25% 27742979166206700793970535921354744095 100.86.12.224datacenter1 rack1 Up Normal 5.01 GB 6.58% 38945137636148605752956920077679425910 ERROR: root@ip bin]# ./nodetool -h100.86.17.90 decommission Exception in thread main java.lang.UnsupportedOperationException at java.util.AbstractList.remove(AbstractList.java:144) at java.util.AbstractList$Itr.remove(AbstractList.java:360) at java.util.AbstractCollection.removeAll(AbstractCollection.java:337) at org.apache.cassandra.service.StorageService.calculatePendingRanges(StorageService.java:1041) at org.apache.cassandra.service.StorageService.calculatePendingRanges(StorageService.java:1006) at org.apache.cassandra.service.StorageService.handleStateLeaving(StorageService.java:877) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:732) at org.apache.cassandra.gms.Gossiper.doNotifications(Gossiper.java:839) at org.apache.cassandra.gms.Gossiper.addLocalApplicationState(Gossiper.java:986) at org.apache.cassandra.service.StorageService.startLeaving(StorageService.java:1836) at org.apache.cassandra.service.StorageService.decommission(StorageService.java:1855) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1426) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1264) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1359) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at
[jira] [Created] (CASSANDRA-3124) java heap limit for nodetool
java heap limit for nodetool Key: CASSANDRA-3124 URL: https://issues.apache.org/jira/browse/CASSANDRA-3124 Project: Cassandra Issue Type: Improvement Components: Core, Tools Affects Versions: 0.8.4, 0.8.3, 0.8.2, 0.8.1 Environment: not important Reporter: Zenek Kraweznik Priority: Minor by defaull (from debian package) # nodetool Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. # and: --- /usr/bin/nodetool.old 2011-09-02 14:15:14.228152799 +0200 +++ /usr/bin/nodetool 2011-09-02 14:14:28.745154552 +0200 @@ -55,7 +55,7 @@ ;; esac -$JAVA -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ +$JAVA -Xmx32m -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ -Dlog4j.configuration=log4j-tools.properties \ org.apache.cassandra.tools.NodeCmd $@ after every upgrade i had to add limit manually. I think it's good idea to add it by default ;) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3031) Add 4 byte integer type
[ https://issues.apache.org/jira/browse/CASSANDRA-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095937#comment-13095937 ] Jonathan Ellis commented on CASSANDRA-3031: --- What would be the effects of upgrading for CQL users who created a CF with a field of type int? Add 4 byte integer type --- Key: CASSANDRA-3031 URL: https://issues.apache.org/jira/browse/CASSANDRA-3031 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.4 Environment: any Reporter: Radim Kolar Priority: Minor Labels: hector, lhf Fix For: 1.0 Attachments: apache-cassandra-0.8.4-SNAPSHOT.jar, src.diff, test.diff Cassandra currently lacks support for 4byte fixed size integer data type. Java API Hector and C libcassandra likes to serialize integers as 4 bytes in network order. Problem is that you cant use cassandra-cli to manipulate stored rows. Compatibility with other applications using api following cassandra integer encoding standard is problematic too. Because adding new datatype/validator is fairly simple I recommend to add int4 data type. Compatibility with hector is important because it is most used Java cassandra api and lot of applications are using it. This problem was discussed several times already http://comments.gmane.org/gmane.comp.db.hector.user/2125 https://issues.apache.org/jira/browse/CASSANDRA-2585 It would be nice to have compatibility with cassandra-cli and other applications without rewriting hector apps. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3031) Add 4 byte integer type
[ https://issues.apache.org/jira/browse/CASSANDRA-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095938#comment-13095938 ] Jonathan Ellis commented on CASSANDRA-3031: --- Also: why not just use varint/IntegerType? Add 4 byte integer type --- Key: CASSANDRA-3031 URL: https://issues.apache.org/jira/browse/CASSANDRA-3031 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.4 Environment: any Reporter: Radim Kolar Priority: Minor Labels: hector, lhf Fix For: 1.0 Attachments: apache-cassandra-0.8.4-SNAPSHOT.jar, src.diff, test.diff Cassandra currently lacks support for 4byte fixed size integer data type. Java API Hector and C libcassandra likes to serialize integers as 4 bytes in network order. Problem is that you cant use cassandra-cli to manipulate stored rows. Compatibility with other applications using api following cassandra integer encoding standard is problematic too. Because adding new datatype/validator is fairly simple I recommend to add int4 data type. Compatibility with hector is important because it is most used Java cassandra api and lot of applications are using it. This problem was discussed several times already http://comments.gmane.org/gmane.comp.db.hector.user/2125 https://issues.apache.org/jira/browse/CASSANDRA-2585 It would be nice to have compatibility with cassandra-cli and other applications without rewriting hector apps. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3122: -- Reviewer: slebresne Fix Version/s: 0.8.5 SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Priority: Minor Fix For: 0.8.5 Attachments: SSTableSimpleUnsortedWriter-v2.patch, SSTableSimpleUnsortedWriter.patch In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3124) java heap limit for nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095939#comment-13095939 ] Jonathan Ellis commented on CASSANDRA-3124: --- What JVM/platform are you running on that this is a problem? java heap limit for nodetool Key: CASSANDRA-3124 URL: https://issues.apache.org/jira/browse/CASSANDRA-3124 Project: Cassandra Issue Type: Improvement Components: Core, Tools Affects Versions: 0.8.1, 0.8.2, 0.8.3, 0.8.4 Environment: not important Reporter: Zenek Kraweznik Priority: Minor by defaull (from debian package) # nodetool Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. # and: --- /usr/bin/nodetool.old 2011-09-02 14:15:14.228152799 +0200 +++ /usr/bin/nodetool 2011-09-02 14:14:28.745154552 +0200 @@ -55,7 +55,7 @@ ;; esac -$JAVA -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ +$JAVA -Xmx32m -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ -Dlog4j.configuration=log4j-tools.properties \ org.apache.cassandra.tools.NodeCmd $@ after every upgrade i had to add limit manually. I think it's good idea to add it by default ;) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3124) java heap limit for nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095940#comment-13095940 ] Zenek Kraweznik commented on CASSANDRA-3124: # dpkg -l | grep java ii java-common 0.40 Base of all Java packages ii libcommons-daemon-java 1.0.2-2 library to launch Java applications as daemons ii libjna-java 3.2.7-4 Dynamic access of native libraries from Java without JNI ii sun-java6-bin6.26-0squeeze1 Sun Java(TM) Runtime Environment (JRE) 6 (architecture dependent files) ii sun-java6-jre6.26-0squeeze1 Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files) # java heap limit for nodetool Key: CASSANDRA-3124 URL: https://issues.apache.org/jira/browse/CASSANDRA-3124 Project: Cassandra Issue Type: Improvement Components: Core, Tools Affects Versions: 0.8.1, 0.8.2, 0.8.3, 0.8.4 Environment: not important Reporter: Zenek Kraweznik Priority: Minor by defaull (from debian package) # nodetool Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. # and: --- /usr/bin/nodetool.old 2011-09-02 14:15:14.228152799 +0200 +++ /usr/bin/nodetool 2011-09-02 14:14:28.745154552 +0200 @@ -55,7 +55,7 @@ ;; esac -$JAVA -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ +$JAVA -Xmx32m -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ -Dlog4j.configuration=log4j-tools.properties \ org.apache.cassandra.tools.NodeCmd $@ after every upgrade i had to add limit manually. I think it's good idea to add it by default ;) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3124) java heap limit for nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095940#comment-13095940 ] Zenek Kraweznik edited comment on CASSANDRA-3124 at 9/2/11 12:28 PM: - I'm using packages from debian repository, if it's possible I'm using stable version # dpkg -l | grep java ii java-common 0.40 Base of all Java packages ii libcommons-daemon-java 1.0.2-2 library to launch Java applications as daemons ii libjna-java 3.2.7-4 Dynamic access of native libraries from Java without JNI ii sun-java6-bin6.26-0squeeze1 Sun Java(TM) Runtime Environment (JRE) 6 (architecture dependent files) ii sun-java6-jre6.26-0squeeze1 Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files) # was (Author: zenek_kraweznik0): # dpkg -l | grep java ii java-common 0.40 Base of all Java packages ii libcommons-daemon-java 1.0.2-2 library to launch Java applications as daemons ii libjna-java 3.2.7-4 Dynamic access of native libraries from Java without JNI ii sun-java6-bin6.26-0squeeze1 Sun Java(TM) Runtime Environment (JRE) 6 (architecture dependent files) ii sun-java6-jre6.26-0squeeze1 Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files) # java heap limit for nodetool Key: CASSANDRA-3124 URL: https://issues.apache.org/jira/browse/CASSANDRA-3124 Project: Cassandra Issue Type: Improvement Components: Core, Tools Affects Versions: 0.8.1, 0.8.2, 0.8.3, 0.8.4 Environment: not important Reporter: Zenek Kraweznik Priority: Minor by defaull (from debian package) # nodetool Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. # and: --- /usr/bin/nodetool.old 2011-09-02 14:15:14.228152799 +0200 +++ /usr/bin/nodetool 2011-09-02 14:14:28.745154552 +0200 @@ -55,7 +55,7 @@ ;; esac -$JAVA -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ +$JAVA -Xmx32m -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ -Dlog4j.configuration=log4j-tools.properties \ org.apache.cassandra.tools.NodeCmd $@ after every upgrade i had to add limit manually. I think it's good idea to add it by default ;) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095949#comment-13095949 ] T Jake Luciani commented on CASSANDRA-2474: --- What happened to the table:transposed syntax? CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.0 Attachments: screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095954#comment-13095954 ] Jonathan Ellis commented on CASSANDRA-2474: --- bq. Can be used as a replacement for componentX I think the goal should be to make it look more like SQL when that is reasonable. bq. when we want to extend 2e1c3308,cscotta with location we can simply update old column's name to 2e1c3308,cscotta,location That would imply a rename column operation. I don't want to go there. CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.0 Attachments: screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095962#comment-13095962 ] Pavel Yaskevich commented on CASSANDRA-2474: bq. I think the goal should be to make it look more like SQL when that is reasonable. I hope that the main goal here is to give end-user clean syntax instead of trying to be as SQL as possible in all the cases. bq. That would imply a rename column operation. I don't want to go there. I guess I described it wrong - we can insert new column with name 2e1c3308,cscotta,location and still use 1/0/-1 as 'end-of-component' byte for querying. Is there any reason why we should delete 2e1c3308,cscotta I'm missing? CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.0 Attachments: screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095967#comment-13095967 ] Jérémy Sevellec commented on CASSANDRA-2961: What do you think about : - create a Map of expireTimeEndpointMap into Gossiper wich store endpoints as key and expireTime as value. - SS, when a state change : - if STATUS is REMOVED_TOKEN or STATUS_LEFT, extract the expireTime in the string a the end of the VV and call the Gossiper to add the endpoint/expireTime into the expireTimeEndpointMap. For all other state - for all other STATUS, call the gossiper to remove the endpoint into expireTimeEndpointMap if it is present. - Gossiper, when doing status check for each endpoint, verifying if there is an expireTime in expireTimeEndpointMap for this endpoint, if so, we have an expireTime, if not, expireTime is set with aVeryLongTime. test and evict if necessary the endpoint. It makes sense for you? (I describe a lot... sorry but i would like to be sure of good understanding all aspect of the problem...) Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Fix For: 1.0 Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095968#comment-13095968
]
Jonathan Ellis commented on CASSANDRA-2474:
---
bq. I hope that the main goal here is to give end-user clean syntax instead of
trying to be as SQL as possible in all the cases.
Please give an example then, preferably using either the tweet or stockhist
examples, of how this syntax improves things.
bq. Is there any reason why we should delete 2e1c3308,cscotta I'm missing?
Yes, because the goal is to go from a resultset like this
{code}
tweet_id username body
2e1c3308 cscotta Brother...
2debb66c WernerWhy ...
2f941d9a hlshipIgor ...
{code}
To this:
{code}
tweet_id username bodylocation
2e1c3308 cscotta Brother... CA
2debb66c WernerWhy ...
2f941d9a hlshipIgor ...
{code}
Not this:
{code}
tweet_id username bodylocation
2e1c3308 cscotta Brother... CA
2e1c3308 cscotta Brother...
2debb66c WernerWhy ...
2f941d9a hlshipIgor ...
{code}
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: Sub-task
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.0
Attachments: screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3123) Don't try to build secondary indexes when there is none
[ https://issues.apache.org/jira/browse/CASSANDRA-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095972#comment-13095972 ] Jonathan Ellis commented on CASSANDRA-3123: --- If we're going to change to relying on the build method to recognize it was asked to perform a no-op and bail early, we should call it maybeBuild... or similar and add javadoc so it's clear that it might be a no-op. Don't try to build secondary indexes when there is none --- Key: CASSANDRA-3123 URL: https://issues.apache.org/jira/browse/CASSANDRA-3123 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 0.8.5 Attachments: 3123.patch buildSecondaryIndexes() is sometimes called without checking the cfs has secondary indexes. Has a result, it prints a useless message and will trigger a bunch of useless action (among which, a full scan of the indexed column family). This is not a huge problem in 0.8 because only the fairly new loadNewSSTables() call does this (which doesn't mean we should fix it). But in trunk, it does this after every streamIn session. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2936) improve dependency situation between JDBC driver and Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095979#comment-13095979
]
Rick Shaw commented on CASSANDRA-2936:
--
+1
Lets get this baby in Trunk.
improve dependency situation between JDBC driver and Cassandra
--
Key: CASSANDRA-2936
URL: https://issues.apache.org/jira/browse/CASSANDRA-2936
Project: Cassandra
Issue Type: Improvement
Components: API, Core
Affects Versions: 0.8.1
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 1.0
Attachments:
v3-0001-CASSANDRA-2936-create-package-for-CQL-term-marshaling.txt,
v3-0002-convert-drivers-and-tests-to-o.a.c.cql.term.txt,
v3-0003-remove-extraneous-methods-from-o.a.c.db.marshal-classe.txt,
v3-0004-make-better-reuse-of-new-classes.txt, v3-0005-create-jar-file.txt
The JDBC jar currently depends on the {{apache-cassandra-$version}} jar,
despite the fact that it only (directly) uses a handful of Cassandra's
classes. In a perfect world, we'd break those classes out into their own jar
which both the JDBC driver and Cassandra (ala
{{apache-cassandra-$version.jar}}) could depend on. However, the classes
used directly don't fall out to anything that makes much sense
organizationally (short of creating a
{{apache-cassandra-misc-$version.jar}}), and the situation only gets worse
when you take into account all of the transitive dependencies.
See CASSANDRA-2761 for more background, in particular
([this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13048734page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13048734]
and
[this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13050884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050884])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095977#comment-13095977
]
Pavel Yaskevich commented on CASSANDRA-2474:
bq. Please give an example then, preferably using either the tweet or stockhist
examples, of how this syntax improves things.
Using ComponentX
{noformat}
SELECT component1 AS tweet_id, component2 AS username, component3 location,
value AS body
FROM timeline:transposed
WHERE user_id = '95a789a'
{noformat}
vs. (..,..,..) notation from my previous comments
{noformat}
SELECT name AS (tweet_id, username, location), value AS body
FROM timeline:transposed
WHERE tweet_id = '95a789a'
{noformat}
bq. Yes, because the goal is to go from a resultset like this
Oh, I see now, we will need to delete old column any time we would need to add
or remove name component...
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: Sub-task
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.0
Attachments: screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3125) Move gossip library into a standalone artifact
Move gossip library into a standalone artifact --- Key: CASSANDRA-3125 URL: https://issues.apache.org/jira/browse/CASSANDRA-3125 Project: Cassandra Issue Type: Task Reporter: Jake Farrell Priority: Minor There has been some talk on the mailing list of people want to use the gossip portion of cassandra in their own applications. The goal for this will be to create a standalone artifact -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3125) Move gossip library into a standalone artifact
[ https://issues.apache.org/jira/browse/CASSANDRA-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell reassigned CASSANDRA-3125: --- Assignee: Jake Farrell Move gossip library into a standalone artifact --- Key: CASSANDRA-3125 URL: https://issues.apache.org/jira/browse/CASSANDRA-3125 Project: Cassandra Issue Type: Task Reporter: Jake Farrell Assignee: Jake Farrell Priority: Minor There has been some talk on the mailing list of people want to use the gossip portion of cassandra in their own applications. The goal for this will be to create a standalone artifact -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095996#comment-13095996 ] Jonathan Ellis commented on CASSANDRA-2474: --- Ah, I see. Sure, that's reasonable. I like it. But how do you apply that to the first composite model, with the sparse fields? CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.0 Attachments: screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3124) java heap limit for nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095998#comment-13095998 ] Jonathan Ellis commented on CASSANDRA-3124: --- Oracle documentation says The default heap size for all 32-bit J2SE implementations is 64MB. We have adjusted the defaults for 64-bit implementations to be 30% larger in order to make up for the increased size of Java objects due to larger native pointers. java heap limit for nodetool Key: CASSANDRA-3124 URL: https://issues.apache.org/jira/browse/CASSANDRA-3124 Project: Cassandra Issue Type: Improvement Components: Core, Tools Affects Versions: 0.8.1, 0.8.2, 0.8.3, 0.8.4 Environment: not important Reporter: Zenek Kraweznik Priority: Minor by defaull (from debian package) # nodetool Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. # and: --- /usr/bin/nodetool.old 2011-09-02 14:15:14.228152799 +0200 +++ /usr/bin/nodetool 2011-09-02 14:14:28.745154552 +0200 @@ -55,7 +55,7 @@ ;; esac -$JAVA -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ +$JAVA -Xmx32m -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ -Dlog4j.configuration=log4j-tools.properties \ org.apache.cassandra.tools.NodeCmd $@ after every upgrade i had to add limit manually. I think it's good idea to add it by default ;) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3010) Java CQL command-line shell
[ https://issues.apache.org/jira/browse/CASSANDRA-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096003#comment-13096003 ] Saulius Menkevicius commented on CASSANDRA-3010: Another argument for non-python cqlsh is that cqlsh given from datastax wouldn't even start on windows due to the readline pypi package not being available for windows. D:\python-ve\Scriptscqlsh.bat Traceback (most recent call last): File cqlsh, line 24, in module import readline ImportError: No module named readline D:\python-ve\Scriptspip install readline Downloading/unpacking readline Downloading readline-6.2.1.tar.gz (2.3Mb): 2.3Mb downloaded Running setup.py egg_info for package readline error: this module is not meant to work on Windows Complete output from command python setup.py egg_info: error: this module is not meant to work on Windows Command python setup.py egg_info failed with error code 1 Java CQL command-line shell --- Key: CASSANDRA-3010 URL: https://issues.apache.org/jira/browse/CASSANDRA-3010 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.0 We need a real CQL shell that: - does not require installing additional environments - includes show keyspaces and other introspection tools - does not break existing cli scripts I.e., it needs to be java, but it should be a new tool instead of replacing the existing cli. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3015) Inter-Node Compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3015: --- Attachment: compress-lzf-0.8.4.jar CASSANDRA-3015.patch Inter-Node Compression -- Key: CASSANDRA-3015 URL: https://issues.apache.org/jira/browse/CASSANDRA-3015 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Labels: streaming Fix For: 1.0 Attachments: 0001-stream-based-compression.patch, CASSANDRA-3015.patch, compress-lzf-0.8.4.jar Although we have CASSANDRA-47 for on-disk the code used for streaming actually sends un-compressed blocks over the wire. I propose we compress this data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3010) Java CQL command-line shell
[ https://issues.apache.org/jira/browse/CASSANDRA-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096010#comment-13096010 ] Jonathan Ellis commented on CASSANDRA-3010: --- Good point. There is pyreadline for windows [1] but it looks a little raw. [2] [1] https://launchpad.net/pyreadline [2] https://answers.launchpad.net/pyreadline/+question/140906 Java CQL command-line shell --- Key: CASSANDRA-3010 URL: https://issues.apache.org/jira/browse/CASSANDRA-3010 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.0 We need a real CQL shell that: - does not require installing additional environments - includes show keyspaces and other introspection tools - does not break existing cli scripts I.e., it needs to be java, but it should be a new tool instead of replacing the existing cli. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2606) Expose through JMX the ability to repair only the primary range
[ https://issues.apache.org/jira/browse/CASSANDRA-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096019#comment-13096019 ] Jonathan Ellis commented on CASSANDRA-2606: --- +1 nit: should we call it the partitioner range or something else b/s primary, which has connotations that we'd prefer to avoid? Expose through JMX the ability to repair only the primary range --- Key: CASSANDRA-2606 URL: https://issues.apache.org/jira/browse/CASSANDRA-2606 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: repair Fix For: 1.0 Attachments: 0001-Add-JMX-commands-to-repair-primary-range-v2.patch, 0001-Add-JMX-commands-to-repair-primary-range-v3.patch, 0001-Add-JMX-commands-to-repair-primary-range.patch Original Estimate: 2h Remaining Estimate: 2h CASSANDRA-2324 introduces the ability to do a repair only on a given range. This ticket proposes to add a nodetool repairPrimaryRange to trigger the repair of only the primary range of a node. This allows to repair a full cluster without any work duplication (or at least make it much simpler). This also introdude a global_repair command to clustertool to trigger the primary range repair on each node of the cluster one after another (we could do all in parallel, but that's probably not nice on the cluster). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3015) Inter-Node Compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096022#comment-13096022 ] Sylvain Lebresne commented on CASSANDRA-3015: - Haven't really checked the code here, but it think it could be nice to use the Compressors introduced for the file format instead of hardcoding lzf (but I have nothing against adding a new lzf compressor). And yes, that means we'll need to enrich the Compressor interface to handle streams, but both Snappy and Deflate handle that natively so that will be trivial. Inter-Node Compression -- Key: CASSANDRA-3015 URL: https://issues.apache.org/jira/browse/CASSANDRA-3015 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Labels: streaming Fix For: 1.0 Attachments: 0001-stream-based-compression.patch, CASSANDRA-3015.patch, compress-lzf-0.8.4.jar Although we have CASSANDRA-47 for on-disk the code used for streaming actually sends un-compressed blocks over the wire. I propose we compress this data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2606) Expose through JMX the ability to repair only the primary range
[ https://issues.apache.org/jira/browse/CASSANDRA-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096028#comment-13096028 ] Sylvain Lebresne commented on CASSANDRA-2606: - bq. nit: should we call it the partitioner range or something else b/s primary, which has connotations that we'd prefer to avoid? Agreed, I was thinking the same thing. Not sure 'partitioner range' is really meaningful but I agree that it'll avoid confusion. I was also thinking of 'local range' as an alternative, but it's not really more meaningful, just shorter. Expose through JMX the ability to repair only the primary range --- Key: CASSANDRA-2606 URL: https://issues.apache.org/jira/browse/CASSANDRA-2606 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: repair Fix For: 1.0 Attachments: 0001-Add-JMX-commands-to-repair-primary-range-v2.patch, 0001-Add-JMX-commands-to-repair-primary-range-v3.patch, 0001-Add-JMX-commands-to-repair-primary-range.patch Original Estimate: 2h Remaining Estimate: 2h CASSANDRA-2324 introduces the ability to do a repair only on a given range. This ticket proposes to add a nodetool repairPrimaryRange to trigger the repair of only the primary range of a node. This allows to repair a full cluster without any work duplication (or at least make it much simpler). This also introdude a global_repair command to clustertool to trigger the primary range repair on each node of the cluster one after another (we could do all in parallel, but that's probably not nice on the cluster). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3015) Inter-Node Compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096029#comment-13096029 ] Jonathan Ellis commented on CASSANDRA-3015: --- I'd really like to avoid Yet Another Config Parameter, especially for something like this where the default is probably Just Fine for everyone. I'd almost be ok with use the same compressor that is defined for the sstable blocks but - i'd like to compress-on-stream by default for uncompressed CFs - pavel reports that snappy streaming mode is broken So maybe just use LZF is fine. Especially if you include compression mode in the stream header so we have the option of making it more complex later, w/o compatibility problems. Inter-Node Compression -- Key: CASSANDRA-3015 URL: https://issues.apache.org/jira/browse/CASSANDRA-3015 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Labels: streaming Fix For: 1.0 Attachments: 0001-stream-based-compression.patch, CASSANDRA-3015.patch, compress-lzf-0.8.4.jar Although we have CASSANDRA-47 for on-disk the code used for streaming actually sends un-compressed blocks over the wire. I propose we compress this data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096031#comment-13096031 ] Gary Dusbabek commented on CASSANDRA-1391: -- bq. Merge algorithm is based on isolated schema initialized from merging migration lastVersion point: merging migration applied first then all older migrations, after that Schema.instance gets safely updated. Could you clarify what you mean by merging migration applied first, then all older migrations...? It seems like a side effect of applying a migration is that it can apply other migrations. Does MigrationManager.applyMigrations() need to be updated because of this? What does isolated indicate? Try to put things like flushSystemTables() in a separate patch (ok on the same ticket) to make reviewing the actual changes easier. Would it be possible to create some unit tests for CFMD.diff()? Allow Concurrent Schema Migrations -- Key: CASSANDRA-1391 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: CASSANDRA-1391.patch CASSANDRA-1292 fixed multiple migrations started from the same node to properly queue themselves, but it is still possible for migrations initiated on different nodes to conflict and leave the cluster in a bad state. Since the system_add/drop/rename methods are accessible directly from the client API, they should be completely safe for concurrent use. It should be possible to allow for most types of concurrent migrations by converting the UUID schema ID into a VersionVectorClock (as provided by CASSANDRA-580). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3015) Inter-Node Compression
[
https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096030#comment-13096030
]
Pavel Yaskevich commented on CASSANDRA-3015:
I have tried using Snappy{Input/Output}Stream and they don't work (it just
throws EOFException in the middle of the transfer) and causes stream to retry.
do we really want to make streaming compression pluggable?
Inter-Node Compression
--
Key: CASSANDRA-3015
URL: https://issues.apache.org/jira/browse/CASSANDRA-3015
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Benjamin Coverston
Assignee: Pavel Yaskevich
Labels: streaming
Fix For: 1.0
Attachments: 0001-stream-based-compression.patch,
CASSANDRA-3015.patch, compress-lzf-0.8.4.jar
Although we have CASSANDRA-47 for on-disk the code used for streaming
actually sends un-compressed blocks over the wire. I propose we compress this
data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-3122: Attachment: 3122.patch As said on the mailing list, though that solution does improve performance, I think we can do better, by simply having the insertions go into the previous column family when we reopen a row instead of creating a new column family each time and copying everything to the previous one afterwards. Attaching patch (3122.patch) that does just this. Note that this patch also fix a bug by which the last row wasn't written and add a unit test for the UnsortedWriter. SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Priority: Minor Fix For: 0.8.5 Attachments: 3122.patch, SSTableSimpleUnsortedWriter-v2.patch, SSTableSimpleUnsortedWriter.patch In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096036#comment-13096036 ] Benoit Perroud commented on CASSANDRA-3122: --- That's even better that way. Thanks ! SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Priority: Minor Fix For: 0.8.5 Attachments: 3122.patch, SSTableSimpleUnsortedWriter-v2.patch, SSTableSimpleUnsortedWriter.patch In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096045#comment-13096045 ] Pavel Yaskevich commented on CASSANDRA-1391: bq. Could you clarify what you mean by merging migration applied first, then all older migrations...? Take a look at the Migration.apply() starting from line 114 and Migration.tryMerge methods if we detect that current migration is outdated and should be merged we do the following actions: - initialize isolated Schema from the point of migration's lastVersion (this sets isolated = true) - reload migration's system definition to reflect that isolated schema - call applyModels on the merging migration to apply it's schema changes - merge phrase: - read from SystemTable.Migrations all migrations that go after current - for each of those migrations: - replaces their schema with isolated (from merging migration) and reload system definition - call apply() method to re-write records in SystemTable.Migrations and SystemTable.Schema - after all migrations were applied we try to merge isolated schema with current system schema (Schema.instance) - flush system tables to persist changes bq. It seems like a side effect of applying a migration is that it can apply other migrations. Does MigrationManager.applyMigrations() need to be updated because of this? No because all modifications are done using isolated schema bq. What does isolated indicate? Isolated indicates that migration will be applied with isolated Schema so no real file operations are going to be made, such as snapshot, create of the keyspace directory, remove of the SSTable files etc. bq. Try to put things like flushSystemTables() in a separate patch (ok on the same ticket) to make reviewing the actual changes easier. I see only one such a refactoring change, is it really worse splitting current patch? bq. Would it be possible to create some unit tests for CFMD.diff() CFMD.diff is used all over the place so if it was broken other tests would fail but if you think that this is necessary I can do that. Allow Concurrent Schema Migrations -- Key: CASSANDRA-1391 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: CASSANDRA-1391.patch CASSANDRA-1292 fixed multiple migrations started from the same node to properly queue themselves, but it is still possible for migrations initiated on different nodes to conflict and leave the cluster in a bad state. Since the system_add/drop/rename methods are accessible directly from the client API, they should be completely safe for concurrent use. It should be possible to allow for most types of concurrent migrations by converting the UUID schema ID into a VersionVectorClock (as provided by CASSANDRA-580). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096045#comment-13096045 ] Pavel Yaskevich edited comment on CASSANDRA-1391 at 9/2/11 3:27 PM: bq. Could you clarify what you mean by merging migration applied first, then all older migrations...? Take a look at the Migration.apply() starting from line 114 and Migration.tryMerge methods if we detect that current migration is outdated and should be merged we do the following actions: - initialize isolated Schema from the point of migration's lastVersion (this sets isolated = true) - reload migration's system definition to reflect that isolated schema - call applyModels on the merging migration to apply it's schema changes - merge phrase: -- read from SystemTable.Migrations all migrations that go after current -- for each of those migrations: --- replaces their schema with isolated (from merging migration) and reload system definition --- call apply() method to re-write records in SystemTable.Migrations and SystemTable.Schema - after all migrations were applied we try to merge isolated schema with current system schema (Schema.instance) - flush system tables to persist changes bq. It seems like a side effect of applying a migration is that it can apply other migrations. Does MigrationManager.applyMigrations() need to be updated because of this? No because all modifications are done using isolated schema bq. What does isolated indicate? Isolated indicates that migration will be applied with isolated Schema so no real file operations are going to be made, such as snapshot, create of the keyspace directory, remove of the SSTable files etc. bq. Try to put things like flushSystemTables() in a separate patch (ok on the same ticket) to make reviewing the actual changes easier. I see only one such a refactoring change, is it really worse splitting current patch? bq. Would it be possible to create some unit tests for CFMD.diff() CFMD.diff is used all over the place so if it was broken other tests would fail but if you think that this is necessary I can do that. was (Author: xedin): bq. Could you clarify what you mean by merging migration applied first, then all older migrations...? Take a look at the Migration.apply() starting from line 114 and Migration.tryMerge methods if we detect that current migration is outdated and should be merged we do the following actions: - initialize isolated Schema from the point of migration's lastVersion (this sets isolated = true) - reload migration's system definition to reflect that isolated schema - call applyModels on the merging migration to apply it's schema changes - merge phrase: - read from SystemTable.Migrations all migrations that go after current - for each of those migrations: - replaces their schema with isolated (from merging migration) and reload system definition - call apply() method to re-write records in SystemTable.Migrations and SystemTable.Schema - after all migrations were applied we try to merge isolated schema with current system schema (Schema.instance) - flush system tables to persist changes bq. It seems like a side effect of applying a migration is that it can apply other migrations. Does MigrationManager.applyMigrations() need to be updated because of this? No because all modifications are done using isolated schema bq. What does isolated indicate? Isolated indicates that migration will be applied with isolated Schema so no real file operations are going to be made, such as snapshot, create of the keyspace directory, remove of the SSTable files etc. bq. Try to put things like flushSystemTables() in a separate patch (ok on the same ticket) to make reviewing the actual changes easier. I see only one such a refactoring change, is it really worse splitting current patch? bq. Would it be possible to create some unit tests for CFMD.diff() CFMD.diff is used all over the place so if it was broken other tests would fail but if you think that this is necessary I can do that. Allow Concurrent Schema Migrations -- Key: CASSANDRA-1391 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: CASSANDRA-1391.patch CASSANDRA-1292 fixed multiple migrations started from the same node to properly queue themselves, but it is still possible for migrations initiated on different nodes to conflict and leave the cluster in a bad state. Since the system_add/drop/rename methods are accessible directly from the client API, they should be
[jira] [Commented] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096053#comment-13096053 ] Jonathan Ellis commented on CASSANDRA-3122: --- I don't understand how the changes to writeRow work without doing anything to cF b/s asking for its serializedSize. nit: unused imports in SimpleUnsorted. SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Priority: Minor Fix For: 0.8.5 Attachments: 3122.patch, SSTableSimpleUnsortedWriter-v2.patch, SSTableSimpleUnsortedWriter.patch In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096057#comment-13096057 ] Brandon Williams commented on CASSANDRA-2961: - This sounds good, a couple of points though: bq. for all other STATUS, call the gossiper to remove the endpoint into expireTimeEndpointMap if it is present. REMOVED_TOKEN and STATUS_LEFT are the only states we need to worry about expiring. bq. Gossiper, when doing status check for each endpoint, verifying if there is an expireTime in expireTimeEndpointMap for this endpoint, if so, we have an expireTime, if not, expireTime is set with aVeryLongTime. test and evict if necessary the endpoint. I think if there is no expireTime we should just respect aVLT as we currently do, instead of populating expireTimeEndpointMap. That way when debugging we can tell if the remote side gave us an expireTime or not, otherwise it won't be distinguishable. Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Fix For: 1.0 Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096066#comment-13096066
]
Pavel Yaskevich commented on CASSANDRA-2474:
For sparse field a propose following syntax
to list exact aliases you want to include into result
{noformat}
SELECT name as (tweet_id, username|body)
{noformat}
if you want to return any component names ? can be used
{noformat}
SELECT name as (tweet_id, ?)
{noformat}
That is going to return username, body and location
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: Sub-task
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.0
Attachments: screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3015) Inter-Node Compression
[
https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096069#comment-13096069
]
Sylvain Lebresne commented on CASSANDRA-3015:
-
Alright, I'm fine with going with lzf only if that sounds simpler for now. I'm
a little bit surprised that the Snappy streams are broken so badly, but ok.
Btw, this is really only making streams compressed. Did we consider making the
inter-node messages compressed ? I suspect that while very small message may
not be worth it, mutations, reads and other merkle tree messages could make use
of it (especially for cross-datacenter transfer).
On the 'Yet Another Config parameter' debate, I'll note that since 1.0 is not
out, we could still have the option to replace the 'compression' and
'compression_options' config by just one 'compression_options' like:
{noformat}
compression_options = { sstable_compression: SnappyCompressor,
block_length_kb: 32 }
{noformat}
which would allow us later to allow
{noformat}
compression_options = { sstable_compression: SnappyCompressor,
block_length_kb: 32, stream_compression: LZFCompressor }
{noformat}
which imho is fine because (1) it doesn't pollute CfDef and (2) leave the
option of documenting this only in advanced documentation (if the fear is to
not overwhelm new users). Yes, that would make it less like how we deal with
Strategy, but I for one don't care if that give us more flexibility.
Inter-Node Compression
--
Key: CASSANDRA-3015
URL: https://issues.apache.org/jira/browse/CASSANDRA-3015
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Benjamin Coverston
Assignee: Pavel Yaskevich
Labels: streaming
Fix For: 1.0
Attachments: 0001-stream-based-compression.patch,
CASSANDRA-3015.patch, compress-lzf-0.8.4.jar
Although we have CASSANDRA-47 for on-disk the code used for streaming
actually sends un-compressed blocks over the wire. I propose we compress this
data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-957) convenience workflow for replacing dead node
[ https://issues.apache.org/jira/browse/CASSANDRA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096078#comment-13096078 ] Nick Bailey commented on CASSANDRA-957: --- Looks like an onRestart() method was added for the state subscribers. I think it was accidental but looks like your change removes that call and replaces it with markDead(). Was that accidental? convenience workflow for replacing dead node Key: CASSANDRA-957 URL: https://issues.apache.org/jira/browse/CASSANDRA-957 Project: Cassandra Issue Type: Wish Components: Core, Tools Affects Versions: 0.8.2 Reporter: Jonathan Ellis Assignee: Vijay Fix For: 1.0 Attachments: 0001-Support-bringing-back-a-node-to-the-cluster-that-exi.patch, 0001-support-for-replace-token-v3.patch, 0001-support-token-replace-v4.patch, 0001-support-token-replace-v5.patch, 0001-support-token-replace-v6.patch, 0002-Do-not-include-local-node-when-computing-workMap.patch, 0002-hints-on-token-than-ip-v4.patch, 0002-hints-on-token-than-ip-v5.patch, 0002-hints-on-token-than-ip-v6.patch, 0002-upport-for-hints-on-token-v3.patch Original Estimate: 24h Remaining Estimate: 24h Replacing a dead node with a new one is a common operation, but nodetool removetoken followed by bootstrap is inefficient (re-replicating data first to the remaining nodes, then to the new one) and manually bootstrapping to a token just less than the old one's, followed by nodetool removetoken is slightly painful and prone to manual errors. First question: how would you expose this in our tool ecosystem? It needs to be a startup-time option to the new node, so it can't be nodetool, and messing with the config xml definitely takes the convenience out. A one-off -DreplaceToken=XXY argument? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096080#comment-13096080 ] Sylvain Lebresne commented on CASSANDRA-3122: - bq. I don't understand how the changes to writeRow work without doing anything to cF b/s asking for its serializedSize In (the new method) getColumnFamily, when we reuse a previous column family to add new columns to it, we start by removing it's size from the estimate, so that when writeRow is called on the updated cf, by adding the whole size we should still have a good estimate (actually a better one that before because we don't count the row key multiple times anymore). SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Priority: Minor Fix For: 0.8.5 Attachments: 3122.patch, SSTableSimpleUnsortedWriter-v2.patch, SSTableSimpleUnsortedWriter.patch In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3015) Inter-Node Compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096087#comment-13096087 ] Pavel Yaskevich commented on CASSANDRA-3015: If we will decide to make whole messages compressed current thanks changes won't make that hard to do. Inter-Node Compression -- Key: CASSANDRA-3015 URL: https://issues.apache.org/jira/browse/CASSANDRA-3015 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Labels: streaming Fix For: 1.0 Attachments: 0001-stream-based-compression.patch, CASSANDRA-3015.patch, compress-lzf-0.8.4.jar Although we have CASSANDRA-47 for on-disk the code used for streaming actually sends un-compressed blocks over the wire. I propose we compress this data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1164602 - in /cassandra/trunk: ./ src/java/org/apache/cassandra/service/ src/java/org/apache/cassandra/tools/
Author: slebresne
Date: Fri Sep 2 16:12:36 2011
New Revision: 1164602
URL: http://svn.apache.org/viewvc?rev=1164602view=rev
Log:
expose ability to only repair the primary range of a node
patch by slebresne; reviewed by jbellis for CASSANDRA-2606
Modified:
cassandra/trunk/CHANGES.txt
cassandra/trunk/NEWS.txt
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
Modified: cassandra/trunk/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1164602r1=1164601r2=1164602view=diff
==
--- cassandra/trunk/CHANGES.txt (original)
+++ cassandra/trunk/CHANGES.txt Fri Sep 2 16:12:36 2011
@@ -56,6 +56,8 @@
* Make the compression algorithm and chunk length configurable
(CASSANDRA-3001)
* Add throttling for internode streaming (CASSANDRA-3080)
* make the repair of a range repair all replica (CASSANDRA-2610)
+ * expose the ability to repair the first range (as returned by the
+ partitioner) of a node (CASSANDRA-2606)
0.8.5
* fix NPE when encryption_options is unspecified (CASSANDRA-3007)
Modified: cassandra/trunk/NEWS.txt
URL:
http://svn.apache.org/viewvc/cassandra/trunk/NEWS.txt?rev=1164602r1=1164601r2=1164602view=diff
==
--- cassandra/trunk/NEWS.txt (original)
+++ cassandra/trunk/NEWS.txt Fri Sep 2 16:12:36 2011
@@ -38,6 +38,10 @@ Other
when HH is enabled, repair only needs to be run if a node crashes.
- Because of this, read repair is disabled now by default on newly
created ColumnFamilies.
+- It is now possible to repair only the first range returned by the
+ partitioner for a node with `nodetool repair -pr`. It makes it
+ easier/possible to repair a full cluster without any work duplication by
+ running this command on every node of the cluster.
0.8.5
Modified:
cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java?rev=1164602r1=1164601r2=1164602view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java
Fri Sep 2 16:12:36 2011
@@ -1602,9 +1602,8 @@ public class StorageService implements I
public void forceTableRepair(final String tableName, final String...
columnFamilies) throws IOException
{
if (Table.SYSTEM_TABLE.equals(tableName))
-{
return;
-}
+
ListAntiEntropyService.RepairFuture futures = new
ArrayListAntiEntropyService.RepairFuture();
for (Range range : getLocalRanges(tableName))
{
@@ -1632,7 +1631,7 @@ public class StorageService implements I
}
catch (Exception e)
{
-logger_.error(Repair session + future.session + failed.,
e);
+logger_.error(Repair session + future.session.getName() +
failed., e);
failedSession = true;
}
}
@@ -1641,6 +1640,23 @@ public class StorageService implements I
throw new IOException(Some repair session(s) failed (see log for
details).);
}
+public void forceTableRepairPrimaryRange(final String tableName, final
String... columnFamilies) throws IOException
+{
+if (Table.SYSTEM_TABLE.equals(tableName))
+return;
+
+AntiEntropyService.RepairFuture future =
forceTableRepair(getLocalPrimaryRange(), tableName, columnFamilies);
+try
+{
+future.get();
+}
+catch (Exception e)
+{
+logger_.error(Repair session + future.session.getName() +
failed., e);
+throw new IOException(Some repair session(s) failed (see log for
details).);
+}
+}
+
public AntiEntropyService.RepairFuture forceTableRepair(final Range range,
final String tableName, final String... columnFamilies) throws IOException
{
ArrayListString names = new ArrayListString();
Modified:
cassandra/trunk/src/java/org/apache/cassandra/service/StorageServiceMBean.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/service/StorageServiceMBean.java?rev=1164602r1=1164601r2=1164602view=diff
==
---
cassandra/trunk/src/java/org/apache/cassandra/service/StorageServiceMBean.java
(original)
+++
cassandra/trunk/src/java/org/apache/cassandra/service/StorageServiceMBean.java
[jira] [Issue Comment Edited] (CASSANDRA-3015) Inter-Node Compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096087#comment-13096087 ] Pavel Yaskevich edited comment on CASSANDRA-3015 at 9/2/11 4:19 PM: If we will decide to make whole messages compressed current changes won't make that hard to do. was (Author: xedin): If we will decide to make whole messages compressed current thanks changes won't make that hard to do. Inter-Node Compression -- Key: CASSANDRA-3015 URL: https://issues.apache.org/jira/browse/CASSANDRA-3015 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Labels: streaming Fix For: 1.0 Attachments: 0001-stream-based-compression.patch, CASSANDRA-3015.patch, compress-lzf-0.8.4.jar Although we have CASSANDRA-47 for on-disk the code used for streaming actually sends un-compressed blocks over the wire. I propose we compress this data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3015) Inter-Node Compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096096#comment-13096096 ] Jonathan Ellis commented on CASSANDRA-3015: --- bq. we could still have the option to replace the 'compression' and 'compression_options' config by just one 'compression_options' +10 Inter-Node Compression -- Key: CASSANDRA-3015 URL: https://issues.apache.org/jira/browse/CASSANDRA-3015 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Labels: streaming Fix For: 1.0 Attachments: 0001-stream-based-compression.patch, CASSANDRA-3015.patch, compress-lzf-0.8.4.jar Although we have CASSANDRA-47 for on-disk the code used for streaming actually sends un-compressed blocks over the wire. I propose we compress this data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096100#comment-13096100
]
Rick Shaw commented on CASSANDRA-2474:
--
Star (*) would be better... And ? would conflict with {{PreparedStatement}}
type data binding.
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: Sub-task
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.0
Attachments: screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096105#comment-13096105 ] Pavel Yaskevich commented on CASSANDRA-2474: I don't have anything against using star (*). CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.0 Attachments: screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3015) Streams Compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-3015: Summary: Streams Compression (was: Inter-Node Compression) Streams Compression --- Key: CASSANDRA-3015 URL: https://issues.apache.org/jira/browse/CASSANDRA-3015 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Labels: streaming Fix For: 1.0 Attachments: 0001-stream-based-compression.patch, CASSANDRA-3015.patch, compress-lzf-0.8.4.jar Although we have CASSANDRA-47 for on-disk the code used for streaming actually sends un-compressed blocks over the wire. I propose we compress this data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2734) JDBC driver assumes schema is constant for the duration of the connection
[
https://issues.apache.org/jira/browse/CASSANDRA-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-2734:
---
Reviewer: thobbs
JDBC driver assumes schema is constant for the duration of the connection
-
Key: CASSANDRA-2734
URL: https://issues.apache.org/jira/browse/CASSANDRA-2734
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8.0
Reporter: Cathy Daw
Assignee: Jonathan Ellis
Priority: Minor
Labels: cql
Fix For: 1.0
Attachments: 0001-include-schema-with-resultset.patch,
0002-ant-gen-thrift-java.txt, 0003-thrift-gen.txt
*The following statement fails when used with a Statement or
PreparedStatement*
{code}
res = stmt.executeQuery(SELECT bar FROM users);
res.next();
{code}
*Error Message*
{code}
[junit] Testcase: simpleSelect(com.datastax.cql.reproBugTest):Caused
an ERROR
[junit] null
[junit] java.lang.NullPointerException
[junit] at
org.apache.cassandra.cql.jdbc.ColumnDecoder.makeKeyColumn(ColumnDecoder.java:136)
[junit] at
org.apache.cassandra.cql.jdbc.CResultSet.next(CResultSet.java:388)
[junit] at
com.datastax.cql.reproBugTest.simpleSelect(reproBugTest.java:57)
[junit]
[junit]
[junit] Test com.datastax.cql.reproBugTest FAILED
{code}
*Here is a quick repro. Showing that res.next() works with other statements
but not select.*
_Also notice that ResultSet.getMetaData().getColumnCount() always returns
zero._
_I noticed in the existing driver tests similar test cases, so not sure the
issue._
*Steps to run script*
* you will need to drop this in your test directory
* change the package declaration
* ant test -Dtest.name=reproBugTest
{code}
package com.datastax.cql;
import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import org.junit.Test;
public class reproBugTest {
@Test
public void simpleSelect() throws Exception {
Connection connection = null;
ResultSet res;
Statement stmt;
int colCount = 0;
try {
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
// Check create keyspace
connection =
DriverManager.getConnection(jdbc:cassandra:root/root@127.0.0.1:9160/default);
stmt = connection.createStatement();
try {
System.out.println(Running DROP KS Statement);
res = stmt.executeQuery(DROP KEYSPACE ks1);
res.next();
System.out.println(Running CREATE KS Statement);
res = stmt.executeQuery(CREATE KEYSPACE ks1 with
strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
res.next();
} catch (SQLException e) {
if (e.getMessage().startsWith(Keyspace does not exist))
{
res = stmt.executeQuery(CREATE KEYSPACE ks1 with
strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
}
}
connection.close();
// Run Test
connection =
DriverManager.getConnection(jdbc:cassandra:root/root@127.0.0.1:9160/ks1);
stmt = connection.createStatement();
System.out.print(Running CREATE CF Statement);
res = stmt.executeQuery(CREATE COLUMNFAMILY users (KEY varchar
PRIMARY KEY, password varchar, gender varchar, session_token varchar, state
varchar, birth_year bigint));
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.next();
System.out.print(Running INSERT Statement);
res = stmt.executeQuery(INSERT INTO users (KEY, password) VALUES
('user1', 'ch@nge'));
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.next();
System.out.print(Running SELECT Statement);
res = stmt.executeQuery(SELECT bar FROM users);
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.getRow();
res.next();
connection.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
{code}
--
This
[jira] [Created] (CASSANDRA-3126) unable to remove column metadata via CLI
unable to remove column metadata via CLI
Key: CASSANDRA-3126
URL: https://issues.apache.org/jira/browse/CASSANDRA-3126
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Reporter: Radim Kolar
Priority: Minor
I cant find way how to remove all columns definitions without CF import/export.
[default@int4] update column family sipdb with column_metadata = [];
Syntax error at position 51: required (...)+ loop did not match anything at
input ']'
[default@int4] update column family sipdb with column_metadata = [{}];
Command not found: `update column family sipdb with column_metadata = [{}];`.
Type 'help;' or '?' for help.
[default@int4]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3127) Message (inter-node) compression
Message (inter-node) compression Key: CASSANDRA-3127 URL: https://issues.apache.org/jira/browse/CASSANDRA-3127 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Priority: Minor CASSANDRA-3015 adds compression of streams. But it could be useful to also compress some messages. Compressing messages is easy, but what may be little bit trickier is when and what messages to compress to get the best performances. The simple solution would be to just have it either always on or always off. But for very small messages (gossip?) that may be counter-productive. On the other side of the spectrum, this is likely always a good choice to compress for say the exchange of merkle trees across data-centers. We could maybe define a size of messages after which we start to compress. Maybe the option to only compress for cross data-center messages would be useful too (but I may also just be getting carried away). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3126) unable to remove column metadata via CLI
[
https://issues.apache.org/jira/browse/CASSANDRA-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3126:
--
Affects Version/s: (was: 0.8.4)
0.7.0
Fix Version/s: 0.8.5
unable to remove column metadata via CLI
Key: CASSANDRA-3126
URL: https://issues.apache.org/jira/browse/CASSANDRA-3126
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0
Reporter: Radim Kolar
Priority: Minor
Labels: cassandra-cli
Fix For: 0.8.5
I cant find way how to remove all columns definitions without CF
import/export.
[default@int4] update column family sipdb with column_metadata = [];
Syntax error at position 51: required (...)+ loop did not match anything at
input ']'
[default@int4] update column family sipdb with column_metadata = [{}];
Command not found: `update column family sipdb with column_metadata = [{}];`.
Type 'help;' or '?' for help.
[default@int4]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096117#comment-13096117 ] Jérémy Sevellec commented on CASSANDRA-2961: I agree with you about the fact that : REMOVED_TOKEN and STATUS_LEFT are the only states we need to worry about expiring. But if SS : - first receive a change for an endpoint with the status by REMOVED_TOKEN or STATUS_LEFT - and then for this same endpoint receiving an other change with one of other status we have to delete the expireTime because the gossiper will remove this endpoint when expireTime will be exceeded and it must not? no? Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Fix For: 1.0 Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3083) o.a.c.dht.Range.getDifferenceToFetch() depends on StorageService singleton
[ https://issues.apache.org/jira/browse/CASSANDRA-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096119#comment-13096119 ] Tyler Hobbs commented on CASSANDRA-3083: Is there a good reason why instance methods in this class that create new Ranges should not use the instance's partitioner attribute for the new Ranges? And for static functions taking two Ranges, isn't it reasonable to use the partitioner attribute of one of the Range parameters? o.a.c.dht.Range.getDifferenceToFetch() depends on StorageService singleton -- Key: CASSANDRA-3083 URL: https://issues.apache.org/jira/browse/CASSANDRA-3083 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.4 Reporter: Tyler Hobbs Range.getDifferenceToFetch() is handy for doing math with range sets, but it cannot be used outside of a Cassandra instance because it creates new Range objects with the constructor that uses StorageService.getPartitioner(), a static function. Overloading this method to allow a partitioner to be supplied (so that the Range(lhs, rhs, partitioner) ctor can be used) would make this possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096124#comment-13096124 ] Brandon Williams commented on CASSANDRA-2961: - Yes, we'll need to perform housekeeping on expireTimeEndpointMap. The simplest thing to do is delete the entry when marking it alive, since there is no other way for a dead state to change. Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Fix For: 1.0 Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3128) Replace compression and compression_options config parameters by just a compression_options map.
Replace compression and compression_options config parameters by just a
compression_options map.
Key: CASSANDRA-3128
URL: https://issues.apache.org/jira/browse/CASSANDRA-3128
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.0
As suggested on CASSANDRA-3105, as long as 1.0 is not out, we could replace the
'compression' and 'compression_options' parameters by just one that would allow
to write:
{noformat}
compression_options = { sstable_compression: SnappyCompressor,
block_length_kb: 32 }
{noformat}
This would allow for more future-proof, in particular if we decide to make
CASSANDRA-3015 pluggable in the future or for CASSANDRA-3127 as this would
allow us to simply evolve to say:
{noformat}
compression_options = { sstable_compression: SnappyCompressor,
block_length_kb: 32, stream_compression: LZFCompressor }
{noformat}
This has the advantages of (1) not polluting CfDef and (2) leaving the option
of documenting some option only in advanced documentation (if said option is
not meant for new users)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3083) o.a.c.dht.Range.getDifferenceToFetch() depends on StorageService singleton
[ https://issues.apache.org/jira/browse/CASSANDRA-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3083. --- Resolution: Duplicate fixed in CASSANDRA-3108 o.a.c.dht.Range.getDifferenceToFetch() depends on StorageService singleton -- Key: CASSANDRA-3083 URL: https://issues.apache.org/jira/browse/CASSANDRA-3083 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.4 Reporter: Tyler Hobbs Range.getDifferenceToFetch() is handy for doing math with range sets, but it cannot be used outside of a Cassandra instance because it creates new Range objects with the constructor that uses StorageService.getPartitioner(), a static function. Overloading this method to allow a partitioner to be supplied (so that the Range(lhs, rhs, partitioner) ctor can be used) would make this possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3015) Streams Compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096132#comment-13096132 ] Sylvain Lebresne commented on CASSANDRA-3015: - Alright, I've created CASSANDRA-3127 for messages compression and CASSANDRA-3128 for the config parameters change proposed. Let's focus on stream compression with hard-coded lzf for now on this ticket. Streams Compression --- Key: CASSANDRA-3015 URL: https://issues.apache.org/jira/browse/CASSANDRA-3015 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Labels: streaming Fix For: 1.0 Attachments: 0001-stream-based-compression.patch, CASSANDRA-3015.patch, compress-lzf-0.8.4.jar Although we have CASSANDRA-47 for on-disk the code used for streaming actually sends un-compressed blocks over the wire. I propose we compress this data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3123) Don't try to build secondary indexes when there is none
[ https://issues.apache.org/jira/browse/CASSANDRA-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-3123: Attachment: 3123-v2.patch Updated patch with proposed changes Don't try to build secondary indexes when there is none --- Key: CASSANDRA-3123 URL: https://issues.apache.org/jira/browse/CASSANDRA-3123 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 0.8.5 Attachments: 3123-v2.patch, 3123.patch buildSecondaryIndexes() is sometimes called without checking the cfs has secondary indexes. Has a result, it prints a useless message and will trigger a bunch of useless action (among which, a full scan of the indexed column family). This is not a huge problem in 0.8 because only the fairly new loadNewSSTables() call does this (which doesn't mean we should fix it). But in trunk, it does this after every streamIn session. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3095) java.lang.NegativeArraySizeException during compacting large row
[ https://issues.apache.org/jira/browse/CASSANDRA-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096136#comment-13096136 ] Pas commented on CASSANDRA-3095: Hello again, I'm now running 0.8.4-SNAPSHOT ( 4ee2c82690fccaab8a9675ec8717596eaaf0478b ) with just bin/cassandra -f (via screen and without jsvc) and I'm getting EOF after ... exceptions: http://pastebin.com/raw.php?i=AmYUmKDc , I haven't tried scrubbing on this node. (The other nodes: 2 x 0.7.4 nodes, one 0.8.4 node.) java.lang.NegativeArraySizeException during compacting large row Key: CASSANDRA-3095 URL: https://issues.apache.org/jira/browse/CASSANDRA-3095 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Environment: Linux 2.6.26-2-amd64 #1 SMP Thu Feb 11 00:59:32 UTC 2010 x86_64 GNU/Linux JDK 1.6.0_27 (Java 6 update 27), with JNA. Reporter: Pas Attachments: 3095-debug.txt Hello, It's a 4 node ring, 3 on 0.7.4, I've upgraded one to 0.8.4. This particular node was having issues with compaction that's why I've tried the upgrade (it looks likely that this solved the compaction issues). Here's the stack trace from system.log. INFO [CompactionExecutor:22] 2011-08-28 18:12:46,566 CompactionController.java (line 136) Compacting large row (36028797018963968 bytes) incrementally ERROR [CompactionExecutor:22] 2011-08-28 18:12:46,609 AbstractCassandraDaemon.java (line 134) Fatal exception in thread Thread[CompactionExecutor:22,1,main] java.lang.NegativeArraySizeException at org.apache.cassandra.utils.obs.OpenBitSet.init(OpenBitSet.java:85) at org.apache.cassandra.utils.BloomFilter.bucketsFor(BloomFilter.java:56) at org.apache.cassandra.utils.BloomFilter.getFilter(BloomFilter.java:73) at org.apache.cassandra.db.ColumnIndexer.serializeInternal(ColumnIndexer.java:62) at org.apache.cassandra.db.ColumnIndexer.serialize(ColumnIndexer.java:50) at org.apache.cassandra.db.compaction.LazilyCompactedRow.init(LazilyCompactedRow.java:89) at org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:138) at org.apache.cassandra.db.compaction.CompactionIterator.getReduced(CompactionIterator.java:123) at org.apache.cassandra.db.compaction.CompactionIterator.getReduced(CompactionIterator.java:43) at org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:74) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) at org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183) at org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:94) at org.apache.cassandra.db.compaction.CompactionManager.doCompactionWithoutSizeEstimation(CompactionManager.java:569) at org.apache.cassandra.db.compaction.CompactionManager.doCompaction(CompactionManager.java:506) at org.apache.cassandra.db.compaction.CompactionManager$1.call(CompactionManager.java:141) at org.apache.cassandra.db.compaction.CompactionManager$1.call(CompactionManager.java:107) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) 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) We've ~70 files still in f format. And 80 in g. We've ~100 GB of data on this node. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3123) Don't try to build secondary indexes when there is none
[ https://issues.apache.org/jira/browse/CASSANDRA-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096137#comment-13096137 ] Jonathan Ellis commented on CASSANDRA-3123: --- + Don't try to build secondary indexes when there is none --- Key: CASSANDRA-3123 URL: https://issues.apache.org/jira/browse/CASSANDRA-3123 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 0.8.5 Attachments: 3123-v2.patch, 3123.patch buildSecondaryIndexes() is sometimes called without checking the cfs has secondary indexes. Has a result, it prints a useless message and will trigger a bunch of useless action (among which, a full scan of the indexed column family). This is not a huge problem in 0.8 because only the fairly new loadNewSSTables() call does this (which doesn't mean we should fix it). But in trunk, it does this after every streamIn session. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2434) node bootstrapping can violate consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096138#comment-13096138 ] Nick Bailey commented on CASSANDRA-2434: Just as initial feedback, I'm not sure we need a new getRangesWithSources method, especially with so much duplication between them. Seems like strict could be passed to the current method. Also, what about leaving getRangesWithSources how it is and passing strict to getWorkMap? That method can do the endpoint set math if it needs to and throw a more informative exception in the case that strict is set and the endpoint we want to fetch from is dead. node bootstrapping can violate consistency -- Key: CASSANDRA-2434 URL: https://issues.apache.org/jira/browse/CASSANDRA-2434 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Assignee: paul cannon Fix For: 1.1 Attachments: 2434.patch.txt My reading (a while ago) of the code indicates that there is no logic involved during bootstrapping that avoids consistency level violations. If I recall correctly it just grabs neighbors that are currently up. There are at least two issues I have with this behavior: * If I have a cluster where I have applications relying on QUORUM with RF=3, and bootstrapping complete based on only one node, I have just violated the supposedly guaranteed consistency semantics of the cluster. * Nodes can flap up and down at any time, so even if a human takes care to look at which nodes are up and things about it carefully before bootstrapping, there's no guarantee. A complication is that not only does it depend on use-case where this is an issue (if all you ever do you do at CL.ONE, it's fine); even in a cluster which is otherwise used for QUORUM operations you may wish to accept less-than-quorum nodes during bootstrap in various emergency situations. A potential easy fix is to have bootstrap take an argument which is the number of hosts to bootstrap from, or to assume QUORUM if none is given. (A related concern is bootstrapping across data centers. You may *want* to bootstrap to a local node and then do a repair to avoid sending loads of data across DC:s while still achieving consistency. Or even if you don't care about the consistency issues, I don't think there is currently a way to bootstrap from local nodes only.) Thoughts? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1164634 - in /cassandra/branches/cassandra-0.8: CHANGES.txt src/java/org/apache/cassandra/db/ColumnFamilyStore.java src/java/org/apache/cassandra/streaming/StreamInSession.java
Author: slebresne
Date: Fri Sep 2 17:12:56 2011
New Revision: 1164634
URL: http://svn.apache.org/viewvc?rev=1164634view=rev
Log:
Don't try to build secondary indexes when there is none
patch by slebresne; reviewed by jbellis for CASSANDRA-3123
Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/streaming/StreamInSession.java
Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1164634r1=1164633r2=1164634view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Fri Sep 2 17:12:56 2011
@@ -51,6 +51,8 @@
* fix handling of the empty byte buffer by ReversedType (CASSANDRA-3111)
* optionally skip log4j configuration (CASSANDRA-3061)
* bundle sstableloader with the debian package (CASSANDRA-3113)
+ * don't try to build secondary indexes when there is none (CASSANDRA-3123)
+
0.8.4
* include files-to-be-streamed in StreamInSession.getSources (CASSANDRA-2972)
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java?rev=1164634r1=1164633r2=1164634view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
Fri Sep 2 17:12:56 2011
@@ -343,7 +343,7 @@ public class ColumnFamilyStore implement
{
throw new AssertionError(e);
}
-buildSecondaryIndexes(getSSTables(),
FBUtilities.singleton(info.name));
+maybeBuildSecondaryIndexes(getSSTables(),
FBUtilities.singleton(info.name));
SystemTable.setIndexBuilt(table.name,
indexedCfMetadata.cfName);
}
};
@@ -360,8 +360,15 @@ public class ColumnFamilyStore implement
: new
LocalByPartionerType(StorageService.getPartitioner());
}
-public void buildSecondaryIndexes(CollectionSSTableReader sstables,
SortedSetByteBuffer columns)
+/**
+ * Build secondary indexes for the provided {@code columns}.
+ * This does nothing if {@code columns} is empty.
+ */
+public void maybeBuildSecondaryIndexes(CollectionSSTableReader sstables,
SortedSetByteBuffer columns)
{
+if (columns.isEmpty())
+return;
+
logger.info(String.format(Submitting index build of %s for data in
%s,
metadata.comparator.getString(columns),
StringUtils.join(sstables, , )));
Table.IndexBuilder builder = table.createIndexBuilder(this, columns,
new ReducingKeyIterator(sstables));
@@ -542,7 +549,7 @@ public class ColumnFamilyStore implement
data.addSSTables(sstables); // this will call updateCacheSizes() for us
logger.info(Requesting a full secondary index re-build for +
table.name + / + columnFamily);
-buildSecondaryIndexes(sstables, getIndexedColumns());
+maybeBuildSecondaryIndexes(sstables, getIndexedColumns());
logger.info(Setting up new generation: + generation);
fileIndexGenerator.set(generation);
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/streaming/StreamInSession.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/streaming/StreamInSession.java?rev=1164634r1=1164633r2=1164634view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/streaming/StreamInSession.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/streaming/StreamInSession.java
Fri Sep 2 17:12:56 2011
@@ -158,8 +158,8 @@ public class StreamInSession
// build secondary indexes
for (Map.EntryColumnFamilyStore, ListSSTableReader entry :
cfstores.entrySet())
{
-if (entry.getKey() != null
!entry.getKey().getIndexedColumns().isEmpty())
-entry.getKey().buildSecondaryIndexes(entry.getValue(),
entry.getKey().getIndexedColumns());
+if (entry.getKey() != null)
+
entry.getKey().maybeBuildSecondaryIndexes(entry.getValue(),
entry.getKey().getIndexedColumns());
}
// send reply to source that we're done
[jira] [Commented] (CASSANDRA-3095) java.lang.NegativeArraySizeException during compacting large row
[ https://issues.apache.org/jira/browse/CASSANDRA-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096144#comment-13096144 ] Jonathan Ellis commented on CASSANDRA-3095: --- That looks like a standard CASSANDRA-2675 effect. Scrub should fix it. java.lang.NegativeArraySizeException during compacting large row Key: CASSANDRA-3095 URL: https://issues.apache.org/jira/browse/CASSANDRA-3095 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Environment: Linux 2.6.26-2-amd64 #1 SMP Thu Feb 11 00:59:32 UTC 2010 x86_64 GNU/Linux JDK 1.6.0_27 (Java 6 update 27), with JNA. Reporter: Pas Attachments: 3095-debug.txt Hello, It's a 4 node ring, 3 on 0.7.4, I've upgraded one to 0.8.4. This particular node was having issues with compaction that's why I've tried the upgrade (it looks likely that this solved the compaction issues). Here's the stack trace from system.log. INFO [CompactionExecutor:22] 2011-08-28 18:12:46,566 CompactionController.java (line 136) Compacting large row (36028797018963968 bytes) incrementally ERROR [CompactionExecutor:22] 2011-08-28 18:12:46,609 AbstractCassandraDaemon.java (line 134) Fatal exception in thread Thread[CompactionExecutor:22,1,main] java.lang.NegativeArraySizeException at org.apache.cassandra.utils.obs.OpenBitSet.init(OpenBitSet.java:85) at org.apache.cassandra.utils.BloomFilter.bucketsFor(BloomFilter.java:56) at org.apache.cassandra.utils.BloomFilter.getFilter(BloomFilter.java:73) at org.apache.cassandra.db.ColumnIndexer.serializeInternal(ColumnIndexer.java:62) at org.apache.cassandra.db.ColumnIndexer.serialize(ColumnIndexer.java:50) at org.apache.cassandra.db.compaction.LazilyCompactedRow.init(LazilyCompactedRow.java:89) at org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:138) at org.apache.cassandra.db.compaction.CompactionIterator.getReduced(CompactionIterator.java:123) at org.apache.cassandra.db.compaction.CompactionIterator.getReduced(CompactionIterator.java:43) at org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:74) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) at org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183) at org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:94) at org.apache.cassandra.db.compaction.CompactionManager.doCompactionWithoutSizeEstimation(CompactionManager.java:569) at org.apache.cassandra.db.compaction.CompactionManager.doCompaction(CompactionManager.java:506) at org.apache.cassandra.db.compaction.CompactionManager$1.call(CompactionManager.java:141) at org.apache.cassandra.db.compaction.CompactionManager$1.call(CompactionManager.java:107) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) 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) We've ~70 files still in f format. And 80 in g. We've ~100 GB of data on this node. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1164641 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/db/index/ src/java/org/ap
Author: slebresne Date: Fri Sep 2 17:18:50 2011 New Revision: 1164641 URL: http://svn.apache.org/viewvc?rev=1164641view=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/db/ColumnFamilyStore.java cassandra/trunk/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamInSession.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 17:18:50 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1163782 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1163783,1164068-1164069,1164399 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1163783,1164068-1164069,1164399,1164634 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1164641r1=1164640r2=1164641view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Fri Sep 2 17:18:50 2011 @@ -110,6 +110,8 @@ * make Range and Bounds objects client-safe (CASSANDRA-3108) * optionally skip log4j configuration (CASSANDRA-3061) * bundle sstableloader with the debian package (CASSANDRA-3113) + * don't try to build secondary indexes when there is none (CASSANDRA-3123) + 0.8.4 * include files-to-be-streamed in StreamInSession.getSources (CASSANDRA-2972) Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 17:18:50 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-1163782 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1163783,1164068-1164069,1164399 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1163783,1164068-1164069,1164399,1164634 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 17:18:50 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-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1163782 /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:1090934-1125013,1125019-1163783,1164068-1164069,1164399 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1163783,1164068-1164069,1164399,1164634 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 17:18:50 2011 @@ -1,7 +1,7 @@
[jira] [Commented] (CASSANDRA-2606) Expose through JMX the ability to repair only the primary range
[ https://issues.apache.org/jira/browse/CASSANDRA-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096149#comment-13096149 ] Hudson commented on CASSANDRA-2606: --- Integrated in Cassandra #1069 (See [https://builds.apache.org/job/Cassandra/1069/]) expose ability to only repair the primary range of a node patch by slebresne; reviewed by jbellis for CASSANDRA-2606 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1164602 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/NEWS.txt * /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 Expose through JMX the ability to repair only the primary range --- Key: CASSANDRA-2606 URL: https://issues.apache.org/jira/browse/CASSANDRA-2606 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: repair Fix For: 1.0 Attachments: 0001-Add-JMX-commands-to-repair-primary-range-v2.patch, 0001-Add-JMX-commands-to-repair-primary-range-v3.patch, 0001-Add-JMX-commands-to-repair-primary-range.patch Original Estimate: 2h Remaining Estimate: 2h CASSANDRA-2324 introduces the ability to do a repair only on a given range. This ticket proposes to add a nodetool repairPrimaryRange to trigger the repair of only the primary range of a node. This allows to repair a full cluster without any work duplication (or at least make it much simpler). This also introdude a global_repair command to clustertool to trigger the primary range repair on each node of the cluster one after another (we could do all in parallel, but that's probably not nice on the cluster). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096148#comment-13096148 ] Jonathan Ellis commented on CASSANDRA-3122: --- +1 I also note that newSuperColumn in abstract writer is unused. SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Priority: Minor Fix For: 0.8.5 Attachments: 3122.patch, SSTableSimpleUnsortedWriter-v2.patch, SSTableSimpleUnsortedWriter.patch In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1164657 - in /cassandra/branches/cassandra-0.8: ./ src/java/org/apache/cassandra/io/sstable/
Author: slebresne
Date: Fri Sep 2 17:53:05 2011
New Revision: 1164657
URL: http://svn.apache.org/viewvc?rev=1164657view=rev
Log:
Improve SSTableSimpleUnsortedWriter speed with large rows
patch by slebresne; reviewed by jebllis for CASSANDRA-3122
Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableSimpleWriter.java
Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1164657r1=1164656r2=1164657view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Fri Sep 2 17:53:05 2011
@@ -52,6 +52,7 @@
* optionally skip log4j configuration (CASSANDRA-3061)
* bundle sstableloader with the debian package (CASSANDRA-3113)
* don't try to build secondary indexes when there is none (CASSANDRA-3123)
+ * improve SSTableSimpleUnsortedWriter speed for large rows (CASSANDRA-3122)
0.8.4
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java?rev=1164657r1=1164656r2=1164657view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java
Fri Sep 2 17:53:05 2011
@@ -94,7 +94,7 @@ public abstract class AbstractSSTableSim
writeRow(currentKey, columnFamily);
currentKey = StorageService.getPartitioner().decorateKey(key);
-columnFamily = ColumnFamily.create(metadata);
+columnFamily = getColumnFamily();
}
/**
@@ -163,4 +163,6 @@ public abstract class AbstractSSTableSim
public abstract void close() throws IOException;
protected abstract void writeRow(DecoratedKey key, ColumnFamily
columnFamily) throws IOException;
+
+protected abstract ColumnFamily getColumnFamily();
}
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java?rev=1164657r1=1164656r2=1164657view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
Fri Sep 2 17:53:05 2011
@@ -29,6 +29,8 @@ import org.apache.cassandra.db.*;
import org.apache.cassandra.db.marshal.AbstractType;
import org.apache.cassandra.service.StorageService;
+import org.apache.cassandra.utils.ByteBufferUtil;
+
/**
* A SSTable writer that doesn't assume rows are in sorted order.
* This writer buffers rows in memory and then write them all in sorted order.
@@ -68,18 +70,30 @@ public class SSTableSimpleUnsortedWriter
protected void writeRow(DecoratedKey key, ColumnFamily columnFamily)
throws IOException
{
-ColumnFamily previous = keys.put(key, columnFamily);
currentSize += key.key.remaining() + columnFamily.serializedSize() *
1.2;
-// Note that if the row was existing already, our size estimation will
be slightly off
-// since we'll be counting the key multiple times.
-if (previous != null)
-columnFamily.addAll(previous);
-
if (currentSize bufferSize)
sync();
}
+protected ColumnFamily getColumnFamily()
+{
+ColumnFamily previous = keys.get(currentKey);
+// If the CF already exist in memory, we'll just continue adding to it
+if (previous == null)
+{
+previous = ColumnFamily.create(metadata);
+keys.put(currentKey, previous);
+}
+else
+{
+// We will reuse a CF that we have counted already. But because it
will be easier to add the full size
+// of the CF in the next writeRow call than to find out the delta,
we just remove the size until that next call
+currentSize -= currentKey.key.remaining() +
previous.serializedSize() * 1.2;
+}
+return previous;
+}
+
public void close() throws IOException
{
sync();
svn commit: r1164659 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/io/sstable/
Author: slebresne Date: Fri Sep 2 17:59:06 2011 New Revision: 1164659 URL: http://svn.apache.org/viewvc?rev=1164659view=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/AbstractSSTableSimpleWriter.java cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableSimpleWriter.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 17:59:06 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1163782 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1163783,1164068-1164069,1164399,1164634 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1163783,1164068-1164069,1164399,1164634,1164657 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1164659r1=1164658r2=1164659view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Fri Sep 2 17:59:06 2011 @@ -111,6 +111,7 @@ * optionally skip log4j configuration (CASSANDRA-3061) * bundle sstableloader with the debian package (CASSANDRA-3113) * don't try to build secondary indexes when there is none (CASSANDRA-3123) + * improve SSTableSimpleUnsortedWriter speed for large rows (CASSANDRA-3122) 0.8.4 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 17:59:06 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-1163782 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1163783,1164068-1164069,1164399,1164634 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1163783,1164068-1164069,1164399,1164634,1164657 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 17:59:06 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-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1163782 /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:1090934-1125013,1125019-1163783,1164068-1164069,1164399,1164634 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1163783,1164068-1164069,1164399,1164634,1164657 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 2 17:59:06 2011 @@ -1,7 +1,7 @@
[jira] [Resolved] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-3122. - Resolution: Fixed Reviewer: jbellis (was: slebresne) Assignee: Sylvain Lebresne Committed, thanks SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8.5 Attachments: 3122.patch, SSTableSimpleUnsortedWriter-v2.patch, SSTableSimpleUnsortedWriter.patch In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3123) Don't try to build secondary indexes when there is none
[ https://issues.apache.org/jira/browse/CASSANDRA-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096179#comment-13096179 ] Hudson commented on CASSANDRA-3123: --- Integrated in Cassandra-0.8 #312 (See [https://builds.apache.org/job/Cassandra-0.8/312/]) Don't try to build secondary indexes when there is none patch by slebresne; reviewed by jbellis for CASSANDRA-3123 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1164634 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/streaming/StreamInSession.java Don't try to build secondary indexes when there is none --- Key: CASSANDRA-3123 URL: https://issues.apache.org/jira/browse/CASSANDRA-3123 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 0.8.5 Attachments: 3123-v2.patch, 3123.patch buildSecondaryIndexes() is sometimes called without checking the cfs has secondary indexes. Has a result, it prints a useless message and will trigger a bunch of useless action (among which, a full scan of the indexed column family). This is not a huge problem in 0.8 because only the fairly new loadNewSSTables() call does this (which doesn't mean we should fix it). But in trunk, it does this after every streamIn session. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3122) SSTableSimpleUnsortedWriter take long time when inserting big rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096180#comment-13096180 ] Hudson commented on CASSANDRA-3122: --- Integrated in Cassandra-0.8 #312 (See [https://builds.apache.org/job/Cassandra-0.8/312/]) Improve SSTableSimpleUnsortedWriter speed with large rows patch by slebresne; reviewed by jebllis for CASSANDRA-3122 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1164657 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/AbstractSSTableSimpleWriter.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableSimpleWriter.java SSTableSimpleUnsortedWriter take long time when inserting big rows -- Key: CASSANDRA-3122 URL: https://issues.apache.org/jira/browse/CASSANDRA-3122 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8.5 Attachments: 3122.patch, SSTableSimpleUnsortedWriter-v2.patch, SSTableSimpleUnsortedWriter.patch In SSTableSimpleUnsortedWriter, when dealing with rows having a lot of columns, if we call newRow several times (to flush data as soon as possible), the time taken by the newRow() call is increasing non linearly. This is because when newRow is called, we merge the size increasing existing CF with the new one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3129) show schema in CLI outputs invalid text structure that cannot be replayed (easily tweakable though)
show schema in CLI outputs invalid text structure that cannot be replayed
(easily tweakable though)
-
Key: CASSANDRA-3129
URL: https://issues.apache.org/jira/browse/CASSANDRA-3129
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Environment: CentOS 6.0
Linux cassandra2.local 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 19:49:27 BST
2011 x86_64 x86_64 x86_64 GNU/Linux
java version 1.7.0
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Cassandra 0.8.4 from the official tarball, also reproducible on the datastax
0.8.4-1 rpm.
Reporter: Evaldo Gardenali
Priority: Minor
Log explaining the problem. Comments in lines starting with
[default@unknown] connect cassandra2/9160;
Connected to: Lab1 on cassandra2/9160
Create a keyspace with a pretty simple definition
[default@unknown] create keyspace foo
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
f9e13340-d58f-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
Copy the schema so we can paste it later
[default@foo] show schema;
create keyspace foo
and replication_factor = 1
with placement_strategy = 'SimpleStrategy'
and strategy_options = [{replication_factor : 1}];
use foo;
Remove the keyspace, so we can paste the exact same text above
[default@foo] drop keyspace foo;
07c93a70-d590-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
Paste the schema shown above as result of the 'show schema' command
[default@unknown] create keyspace foo
... and replication_factor = 1
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
No enum constant
org.apache.cassandra.cli.CliClient.AddKeyspaceArgument.REPLICATION_FACTOR
Presented an error that should not occur if show schema generated valid
text
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3129) show schema in CLI outputs invalid text structure that cannot be replayed (easily tweakable though)
[
https://issues.apache.org/jira/browse/CASSANDRA-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evaldo Gardenali updated CASSANDRA-3129:
Description:
Log explaining the problem.
[default@unknown] connect cassandra2/9160;
Connected to: Lab1 on cassandra2/9160
* Create a keyspace with a pretty simple definition
[default@unknown] create keyspace foo
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
f9e13340-d58f-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
* Copy the schema so we can paste it later
[default@foo] show schema;
create keyspace foo
and replication_factor = 1
with placement_strategy = 'SimpleStrategy'
and strategy_options = [{replication_factor : 1}];
use foo;
* Remove the keyspace, so we can paste the exact same text above
[default@foo] drop keyspace foo;
07c93a70-d590-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
* Paste the schema shown above as result of the 'show schema' command
[default@unknown] create keyspace foo
... and replication_factor = 1
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
No enum constant
org.apache.cassandra.cli.CliClient.AddKeyspaceArgument.REPLICATION_FACTOR
* Presented an error that should not occur if show schema generated valid text
was:
Log explaining the problem. Comments in lines starting with
[default@unknown] connect cassandra2/9160;
Connected to: Lab1 on cassandra2/9160
Create a keyspace with a pretty simple definition
[default@unknown] create keyspace foo
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
f9e13340-d58f-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
Copy the schema so we can paste it later
[default@foo] show schema;
create keyspace foo
and replication_factor = 1
with placement_strategy = 'SimpleStrategy'
and strategy_options = [{replication_factor : 1}];
use foo;
Remove the keyspace, so we can paste the exact same text above
[default@foo] drop keyspace foo;
07c93a70-d590-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
Paste the schema shown above as result of the 'show schema' command
[default@unknown] create keyspace foo
... and replication_factor = 1
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
No enum constant
org.apache.cassandra.cli.CliClient.AddKeyspaceArgument.REPLICATION_FACTOR
Presented an error that should not occur if show schema generated valid
text
show schema in CLI outputs invalid text structure that cannot be replayed
(easily tweakable though)
-
Key: CASSANDRA-3129
URL: https://issues.apache.org/jira/browse/CASSANDRA-3129
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Environment: CentOS 6.0
Linux cassandra2.local 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 19:49:27
BST 2011 x86_64 x86_64 x86_64 GNU/Linux
java version 1.7.0
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Cassandra 0.8.4 from the official tarball, also reproducible on the datastax
0.8.4-1 rpm.
Reporter: Evaldo Gardenali
Priority: Minor
Log explaining the problem.
[default@unknown] connect cassandra2/9160;
Connected to: Lab1 on cassandra2/9160
* Create a keyspace with a pretty simple definition
[default@unknown] create keyspace foo
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
f9e13340-d58f-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
* Copy the schema so we can paste it later
[default@foo] show schema;
create keyspace foo
and replication_factor = 1
with placement_strategy = 'SimpleStrategy'
and strategy_options = [{replication_factor : 1}];
use foo;
* Remove the keyspace, so we can paste the exact same text above
[default@foo] drop keyspace foo;
07c93a70-d590-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
* Paste the schema shown above as result of the 'show schema' command
[jira] [Updated] (CASSANDRA-3129) show schema in CLI outputs invalid text structure that cannot be replayed (easily tweakable though)
[
https://issues.apache.org/jira/browse/CASSANDRA-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evaldo Gardenali updated CASSANDRA-3129:
Description:
Log explaining the problem. Trouble happens at the and replication_factor = 1
string
[default@unknown] connect cassandra2/9160;
Connected to: Lab1 on cassandra2/9160
* Create a keyspace with a pretty simple definition
[default@unknown] create keyspace foo
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
f9e13340-d58f-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
* Copy the schema so we can paste it later
[default@foo] show schema;
create keyspace foo
and replication_factor = 1
with placement_strategy = 'SimpleStrategy'
and strategy_options = [{replication_factor : 1}];
use foo;
* Remove the keyspace, so we can paste the exact same text above
[default@foo] drop keyspace foo;
07c93a70-d590-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
* Paste the schema shown above as result of the 'show schema' command
[default@unknown] create keyspace foo
... and replication_factor = 1
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
No enum constant
org.apache.cassandra.cli.CliClient.AddKeyspaceArgument.REPLICATION_FACTOR
* Presented an error that should not occur if show schema generated valid text
was:
Log explaining the problem.
[default@unknown] connect cassandra2/9160;
Connected to: Lab1 on cassandra2/9160
* Create a keyspace with a pretty simple definition
[default@unknown] create keyspace foo
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
f9e13340-d58f-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
* Copy the schema so we can paste it later
[default@foo] show schema;
create keyspace foo
and replication_factor = 1
with placement_strategy = 'SimpleStrategy'
and strategy_options = [{replication_factor : 1}];
use foo;
* Remove the keyspace, so we can paste the exact same text above
[default@foo] drop keyspace foo;
07c93a70-d590-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
* Paste the schema shown above as result of the 'show schema' command
[default@unknown] create keyspace foo
... and replication_factor = 1
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
No enum constant
org.apache.cassandra.cli.CliClient.AddKeyspaceArgument.REPLICATION_FACTOR
* Presented an error that should not occur if show schema generated valid text
show schema in CLI outputs invalid text structure that cannot be replayed
(easily tweakable though)
-
Key: CASSANDRA-3129
URL: https://issues.apache.org/jira/browse/CASSANDRA-3129
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Environment: CentOS 6.0
Linux cassandra2.local 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 19:49:27
BST 2011 x86_64 x86_64 x86_64 GNU/Linux
java version 1.7.0
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Cassandra 0.8.4 from the official tarball, also reproducible on the datastax
0.8.4-1 rpm.
Reporter: Evaldo Gardenali
Priority: Minor
Log explaining the problem. Trouble happens at the and replication_factor =
1 string
[default@unknown] connect cassandra2/9160;
Connected to: Lab1 on cassandra2/9160
* Create a keyspace with a pretty simple definition
[default@unknown] create keyspace foo
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
f9e13340-d58f-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
* Copy the schema so we can paste it later
[default@foo] show schema;
create keyspace foo
and replication_factor = 1
with placement_strategy = 'SimpleStrategy'
and strategy_options = [{replication_factor : 1}];
use foo;
* Remove the keyspace, so we can paste the exact same text above
[default@foo] drop keyspace foo;
07c93a70-d590-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
* Paste the
[jira] [Assigned] (CASSANDRA-3129) show schema in CLI outputs invalid text structure that cannot be replayed (easily tweakable though)
[
https://issues.apache.org/jira/browse/CASSANDRA-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-3129:
---
Assignee: Pavel Yaskevich
show schema in CLI outputs invalid text structure that cannot be replayed
(easily tweakable though)
-
Key: CASSANDRA-3129
URL: https://issues.apache.org/jira/browse/CASSANDRA-3129
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Environment: CentOS 6.0
Linux cassandra2.local 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 19:49:27
BST 2011 x86_64 x86_64 x86_64 GNU/Linux
java version 1.7.0
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Cassandra 0.8.4 from the official tarball, also reproducible on the datastax
0.8.4-1 rpm.
Reporter: Evaldo Gardenali
Assignee: Pavel Yaskevich
Priority: Minor
Log explaining the problem. Trouble happens at the and replication_factor =
1 string
[default@unknown] connect cassandra2/9160;
Connected to: Lab1 on cassandra2/9160
* Create a keyspace with a pretty simple definition
[default@unknown] create keyspace foo
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
f9e13340-d58f-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
* Copy the schema so we can paste it later
[default@foo] show schema;
create keyspace foo
and replication_factor = 1
with placement_strategy = 'SimpleStrategy'
and strategy_options = [{replication_factor : 1}];
use foo;
* Remove the keyspace, so we can paste the exact same text above
[default@foo] drop keyspace foo;
07c93a70-d590-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
* Paste the schema shown above as result of the 'show schema' command
[default@unknown] create keyspace foo
... and replication_factor = 1
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
No enum constant
org.apache.cassandra.cli.CliClient.AddKeyspaceArgument.REPLICATION_FACTOR
* Presented an error that should not occur if show schema generated valid text
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1311) Support (asynchronous) triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096204#comment-13096204 ] Edward Capriolo commented on CASSANDRA-1311: I think the work to pick a trigger master is really awesome. Great job, hard problem to solve. I think different people want different things from triggers. The 'internal developers' might want to be able to use triggers to build secondary indexes. They want triggers to happen close to the storage layer in most cases. The 'external users' might want to be able to use triggers to replicate data to another system. They want triggers to be on the coordinating node. What I am proposing is we recognize this and implement two types of triggers. The trigger for 'external users' is the easiest and should be done first. ExternalTriggers have a PreHook and PostHook. External triggers happen on the coordinating node. For the post hook, if an operation succeeds at the client specified consistency level a success_trigger fires. If it does not succeed a failed_trigger fires. The weirdness in external triggers comes from a write timing out on some but not all nodes. That write could succeed on some nodes but not on all. Read repair and hinted handoff could eventually fix this data. This would result in the failed trigger firing but the write eventually succeeding. I argue that this behaviour is undefined. Clients are supposed to replay failed writes until success. Now the fun part, since we can fire a trigger on both success and failure we could theoretically deal with the above weirdness by implementing a guaranteed hinted handoff trigger. This would be done by using the PostHook failed_trigger to delay and then retry the write. Support (asynchronous) triggers --- Key: CASSANDRA-1311 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311 Project: Cassandra Issue Type: New Feature Components: Contrib Reporter: Maxim Grinev Fix For: 1.1 Attachments: HOWTO-PatchAndRunTriggerExample-update1.txt, HOWTO-PatchAndRunTriggerExample.txt, ImplementationDetails-update1.pdf, ImplementationDetails.pdf, trunk-967053.txt, trunk-984391-update1.txt, trunk-984391-update2.txt Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous execution of application code at database side. For example to support indexes and materialized views, online analytics, push-based data propagation. Please find the motivation, triggers description and list of applications: http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/ An example of using triggers for indexing: http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/ Implementation details are attached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3130) CQL queries should alow talbe names to be qualified by keyspace
CQL queries should alow talbe names to be qualified by keyspace
---
Key: CASSANDRA-3130
URL: https://issues.apache.org/jira/browse/CASSANDRA-3130
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
While the 0.6.X api was ugly in terms of method signatures, it did allow you
to use the same client to query multiple keyspaces without having to call
set_keyspace(String). I totally dislike set_keyspace but I know the thrift API
is definitely not changing.
The following command sequence is three RPC operations.
{noformat}
select * from cf;
use otherkeyspace;
select * from othercf;
{noformat}
CQL should allow us to do:
{noformat}
select * from keyspace1.cf;
select * from keyspace2.cf;
{noformat}
This will make the connection pool management on the client much easier.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3015) Streams Compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096229#comment-13096229 ] Jonathan Ellis commented on CASSANDRA-3015: --- +1 CASSANDRA-3015.patch Streams Compression --- Key: CASSANDRA-3015 URL: https://issues.apache.org/jira/browse/CASSANDRA-3015 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Labels: streaming Fix For: 1.0 Attachments: 0001-stream-based-compression.patch, CASSANDRA-3015.patch, compress-lzf-0.8.4.jar Although we have CASSANDRA-47 for on-disk the code used for streaming actually sends un-compressed blocks over the wire. I propose we compress this data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3130) CQL queries should alow talbe names to be qualified by keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3130:
--
Priority: Minor (was: Major)
Fix Version/s: 1.1
CQL queries should alow talbe names to be qualified by keyspace
---
Key: CASSANDRA-3130
URL: https://issues.apache.org/jira/browse/CASSANDRA-3130
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Priority: Minor
Fix For: 1.1
While the 0.6.X api was ugly in terms of method signatures, it did allow
you to use the same client to query multiple keyspaces without having to call
set_keyspace(String). I totally dislike set_keyspace but I know the thrift
API is definitely not changing.
The following command sequence is three RPC operations.
{noformat}
select * from cf;
use otherkeyspace;
select * from othercf;
{noformat}
CQL should allow us to do:
{noformat}
select * from keyspace1.cf;
select * from keyspace2.cf;
{noformat}
This will make the connection pool management on the client much easier.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3129) show schema in CLI outputs invalid text structure that cannot be replayed (easily tweakable though)
[
https://issues.apache.org/jira/browse/CASSANDRA-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3129:
--
Fix Version/s: 0.8.5
show schema in CLI outputs invalid text structure that cannot be replayed
(easily tweakable though)
-
Key: CASSANDRA-3129
URL: https://issues.apache.org/jira/browse/CASSANDRA-3129
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Environment: CentOS 6.0
Linux cassandra2.local 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 19:49:27
BST 2011 x86_64 x86_64 x86_64 GNU/Linux
java version 1.7.0
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Cassandra 0.8.4 from the official tarball, also reproducible on the datastax
0.8.4-1 rpm.
Reporter: Evaldo Gardenali
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.8.5
Log explaining the problem. Trouble happens at the and replication_factor =
1 string
[default@unknown] connect cassandra2/9160;
Connected to: Lab1 on cassandra2/9160
* Create a keyspace with a pretty simple definition
[default@unknown] create keyspace foo
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
f9e13340-d58f-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
* Copy the schema so we can paste it later
[default@foo] show schema;
create keyspace foo
and replication_factor = 1
with placement_strategy = 'SimpleStrategy'
and strategy_options = [{replication_factor : 1}];
use foo;
* Remove the keyspace, so we can paste the exact same text above
[default@foo] drop keyspace foo;
07c93a70-d590-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
* Paste the schema shown above as result of the 'show schema' command
[default@unknown] create keyspace foo
... and replication_factor = 1
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
No enum constant
org.apache.cassandra.cli.CliClient.AddKeyspaceArgument.REPLICATION_FACTOR
* Presented an error that should not occur if show schema generated valid text
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3129) show schema in CLI outputs invalid text structure that cannot be replayed (easily tweakable though)
[
https://issues.apache.org/jira/browse/CASSANDRA-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3129:
---
Attachment: CASSANDRA-3129.patch
show schema in CLI outputs invalid text structure that cannot be replayed
(easily tweakable though)
-
Key: CASSANDRA-3129
URL: https://issues.apache.org/jira/browse/CASSANDRA-3129
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Environment: CentOS 6.0
Linux cassandra2.local 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 19:49:27
BST 2011 x86_64 x86_64 x86_64 GNU/Linux
java version 1.7.0
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Cassandra 0.8.4 from the official tarball, also reproducible on the datastax
0.8.4-1 rpm.
Reporter: Evaldo Gardenali
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.8.5
Attachments: CASSANDRA-3129.patch
Log explaining the problem. Trouble happens at the and replication_factor =
1 string
[default@unknown] connect cassandra2/9160;
Connected to: Lab1 on cassandra2/9160
* Create a keyspace with a pretty simple definition
[default@unknown] create keyspace foo
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
f9e13340-d58f-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
* Copy the schema so we can paste it later
[default@foo] show schema;
create keyspace foo
and replication_factor = 1
with placement_strategy = 'SimpleStrategy'
and strategy_options = [{replication_factor : 1}];
use foo;
* Remove the keyspace, so we can paste the exact same text above
[default@foo] drop keyspace foo;
07c93a70-d590-11e0--e3f60146f2df
Waiting for schema agreement...
... schemas agree across the cluster
* Paste the schema shown above as result of the 'show schema' command
[default@unknown] create keyspace foo
... and replication_factor = 1
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = [{replication_factor : 1}];
No enum constant
org.apache.cassandra.cli.CliClient.AddKeyspaceArgument.REPLICATION_FACTOR
* Presented an error that should not occur if show schema generated valid text
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1311) Support (asynchronous) triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096236#comment-13096236 ] Jonathan Ellis commented on CASSANDRA-1311: --- Fundamentally there is zero value to an app developer from coordinator-run triggers vs running the same code from a well-designed app-side storage layer. This is why I don't think it's worth adding a bunch of fragile scaffolding around it to try to make it kinda halfway work. But replica-level triggers are not simply moving logic from the client to the coordinator. That makes it more interesting, as well as trivially sound via the commitlog. Support (asynchronous) triggers --- Key: CASSANDRA-1311 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311 Project: Cassandra Issue Type: New Feature Components: Contrib Reporter: Maxim Grinev Fix For: 1.1 Attachments: HOWTO-PatchAndRunTriggerExample-update1.txt, HOWTO-PatchAndRunTriggerExample.txt, ImplementationDetails-update1.pdf, ImplementationDetails.pdf, trunk-967053.txt, trunk-984391-update1.txt, trunk-984391-update2.txt Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous execution of application code at database side. For example to support indexes and materialized views, online analytics, push-based data propagation. Please find the motivation, triggers description and list of applications: http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/ An example of using triggers for indexing: http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/ Implementation details are attached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
