[jira] [Updated] (CASSANDRA-5626) Support empty IN queries
[ https://issues.apache.org/jira/browse/CASSANDRA-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Solovyev updated CASSANDRA-5626: -- Description: It would be nice to have support of empty IN queries. Example: SELECT a FROM t WHERE aKey IN (). One of the reasons is to have such support in DataStax Java Driver (see discussion here: https://datastax-oss.atlassian.net/browse/JAVA-106). was: It would be nice to have support of empty IN queries, an example: SELECT a FROM t WHERE aKey IN (). One of the reasons is to have such support in DataStax Java Driver (see discussion here: https://datastax-oss.atlassian.net/browse/JAVA-106). Support empty IN queries Key: CASSANDRA-5626 URL: https://issues.apache.org/jira/browse/CASSANDRA-5626 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Alexander Solovyev It would be nice to have support of empty IN queries. Example: SELECT a FROM t WHERE aKey IN (). One of the reasons is to have such support in DataStax Java Driver (see discussion here: https://datastax-oss.atlassian.net/browse/JAVA-106). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5761) Issue with secondary index sstable.
[ https://issues.apache.org/jira/browse/CASSANDRA-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13710906#comment-13710906 ] Andriy Yevsyukov commented on CASSANDRA-5761: - Hi, anyone, please help with this issue, it's really very critical. Issue with secondary index sstable. --- Key: CASSANDRA-5761 URL: https://issues.apache.org/jira/browse/CASSANDRA-5761 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Andriy Yevsyukov Priority: Critical With Cassandra 1.2.5 having issue very similar to [CASSANDRA-5225|https://issues.apache.org/jira/browse/CASSANDRA-5225] but for secondary index sstable. Every query that uses this index fails in Hector with ConnectionTimeout but cassandra log says that reason is: {noformat} ERROR [ReadStage:55803] 2013-07-15 12:11:35,392 CassandraDaemon.java (line 175) Exception in thread Thread[ReadStage:55803,5,main] java.lang.RuntimeException: org.apache.cassandra.io.sstable.CorruptSSTableException: org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid column name length 0 (/data/cassandra/data/betting/events/betting-events.events_sport_type_idx-ic-1-Data.db, 19658 bytes remaining) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1582) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid column name length 0 (/data/cassandra/data/betting/events/betting-events.events_sport_type_idx-ic-1-Data.db, 19658 bytes remaining) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:108) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:39) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:90) at org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:171) at org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:154) at org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:143) at org.apache.cassandra.utils.MergeIterator$ManyToOne.init(MergeIterator.java:86) at org.apache.cassandra.utils.MergeIterator.get(MergeIterator.java:45) at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:134) at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:84) at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:293) at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:65) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1357) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1214) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1126) at org.apache.cassandra.db.index.keys.KeysSearcher$1.computeNext(KeysSearcher.java:140) at org.apache.cassandra.db.index.keys.KeysSearcher$1.computeNext(KeysSearcher.java:109) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:1466) at org.apache.cassandra.db.index.keys.KeysSearcher.search(KeysSearcher.java:82) at org.apache.cassandra.db.index.SecondaryIndexManager.search(SecondaryIndexManager.java:548) at org.apache.cassandra.db.ColumnFamilyStore.search(ColumnFamilyStore.java:1454) at org.apache.cassandra.service.RangeSliceVerbHandler.executeLocally(RangeSliceVerbHandler.java:44) at org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1076) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1578) ... 3 more Caused by: org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid column name length 0
[jira] [Created] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1
Andy Cobley created CASSANDRA-5768: -- Summary: If a Seed can't be contacted, a new node comes up as a cluster of 1 Key: CASSANDRA-5768 URL: https://issues.apache.org/jira/browse/CASSANDRA-5768 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Andy Cobley Priority: Minor Setting up a new test cluster using 2.0.0-beta1 and I noticed the following behaviour with vnodes turned on. I bring up one node all well and good. however if I bring up a second node, that can't contact the first (the first being the seed for the second) after a short period of time, the second goes ahead and assumes it's the only node and bootstraps with all tokens. NOTE also this email from Robert Coli To: u...@cassandra.apache.org Obviously if you have defined a seed and cannot contact it, the node should not start as a cluster of one. I have a to-do list item to file a JIRA on the subject, but if you wanted to file and link us, that'd be super. :) Startup trace (from the can't contact the seed messages below). DEBUG 17:57:46,134 Target max version is -2147483648; no version information yet, will retry INFO 17:57:46,139 Cannot handshake version with /192.168.0.10 INFO 17:57:46,147 Handshaking version with /192.168.0.10 DEBUG 17:57:51,147 Target max version is -2147483648; no version information yet, will retry INFO 17:57:51,151 Cannot handshake version with /192.168.0.10 DEBUG 17:57:51,156 attempting to connect to /192.168.0.10 INFO 17:57:51,164 Handshaking version with /192.168.0.10 DEBUG 17:57:56,163 Target max version is -2147483648; no version information yet, will retry INFO 17:57:56,168 Cannot handshake version with /192.168.0.10 INFO 17:57:56,177 Handshaking version with /192.168.0.10 DEBUG 17:58:01,176 Target max version is -2147483648; no version information yet, will retry INFO 17:58:01,195 Cannot handshake version with /192.168.0.10 DEBUG 17:58:01,199 attempting to connect to /192.168.0.10 INFO 17:58:01,211 Handshaking version with /192.168.0.10 DEBUG 17:58:06,210 Target max version is -2147483648; no version information yet, will retry INFO 17:58:06,229 Cannot handshake version with /192.168.0.10 INFO 17:58:06,243 Handshaking version with /192.168.0.10 DEBUG 17:58:11,240 Target max version is -2147483648; no version information yet, will retry INFO 17:58:11,257 Cannot handshake version with /192.168.0.10 DEBUG 17:58:11,265 attempting to connect to /192.168.0.10 DEBUG 17:58:11,249 Disseminating load info ... INFO 17:58:11,277 Handshaking version with /192.168.0.10 INFO 17:58:12,918 JOINING: Starting to bootstrap... DEBUG 17:58:12,922 Beginning bootstrap process INFO 17:58:13,065 Bootstrap completed! for the tokens [-6323000812485711377, 7540920246740048508, 8343754522398236724, 8408024349763410671, 2958176648006585896, -4558504792860463383, 6505045068820279515, -2723585437376250373, 6295277530571293136, -632036933490110017, 7076829522639601545, -972040818133908807, -8032509273357338597, -8195415716479930448, 2815056297233670800, -8514945661303914275, -1404986336850055825, 1902287316263855857, 2271127848797136099, 2253027225668615491, -4596682821656889301, -3829603337268068014, 6732451001921723049, -7525322146388049675, -7520469144418445567, -42294142306824200, -3583505036108061780, 2037651260804506174, -8857382013269212764, -287803492046061484, -2387955156962752445, 5851040736860755910, -2566990238894069943, -4862528385953509677, -6934815927114679513, 436339434870862426, -9024405707727859684, -5712896424965939691, -7306151990958768726, 1972562868127181045, 432233230504092, 3274187527528688964, -170723646511099548, -5215516480259793274, -5433009735911985650, 1611629741105319295, -1003574501709202508, -342125947698355485, -6982367747787992083, -1265530805719316699, -3787322892048394796, 4335532059375005778, -4955726035129474058, -3371084287244267978, -1356714364316547864, 2509890377680956235, -1688681099182070115, 4105757083923252042, 6251650102550794764, 6814340446137923947, 2350550282350068760, -5827526901688128468, 6417310693620297152, -3072998771907077372, -1401160349313134159, 5689378233308186158, -4579053362657493044, -1974282572872555977, 6030416333994244776, -6459751443485456668, -7053683753232252424, 3313304008102967685, -3323360202881321267, 1777100483859232105, 644078824255348160, 9174385969124367717, -3152648150979214720, -5810274955975592409, -2417697781941443512, 2097979287894624485, 1306279112226821961, -5471073413421323422, -899964525929809433, 5721993461796585132, 6287709076354945844, -2618973873461192043, -4901233632190356360, 2810307178808259886, 414264499406348099, 9204881637988352346, 2756156004752906240, 4264704223664142541, 6966682145360577932, 456907978019976961, 3526133307919328434, 6663482402885505474, 1208521381475842799, 3709424135702812997, 2664447310834129793,
[jira] [Created] (CASSANDRA-5769) Not all STATUS_CHANGE UP events reported via the native protocol
Duncan Sands created CASSANDRA-5769: --- Summary: Not all STATUS_CHANGE UP events reported via the native protocol Key: CASSANDRA-5769 URL: https://issues.apache.org/jira/browse/CASSANDRA-5769 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.6, 1.2.5 Environment: Uubuntu 12.04, x86, 64 bit Reporter: Duncan Sands Priority: Minor Not all gossip UP events are pushed to native protocol users who have registered for them. This seems to be a native protocol issue because nodes themselves get the UP event (as seen in their logs). I can consistently reproduce this issue as follows: 1) connect a client to a cluster node (node1) using the native protocol, register for TOPOLOGY_CHANGE and STATUS_CHANGE events. (Probably you only need to register for STATUS_CHANGE to see this, however my client registers for both). 2) on another node (node2), send SIGSTOP to the Cassandra process. 3) after about 30 seconds the client gets pushed a STATUS_CHANGE DOWN event for the stopped node. 4) on node2, send SIGCONT to the the Cassandra process. 5) wait forever to get a STATUS_CHANGE UP event. This is failure: no event is ever received. Observe that node1 does know that node2 is back up: in its system log I see for example INFO [GossipStage:1] 2013-07-17 14:27:41,238 Gossiper.java (line 771) InetAddress /172.18.34.169 is now UP shortly after sending SIGCONT to the stopped process. To eliminate the possibility that my client is at fault, I performed the following sanity check: 2') on node2, stopped Cassandra nicely using: sudo service cassandra stop 4') on node2, restarted Cassandra using: sudo service cassandra start In this case the client soon after gets a STATUS_CHANGE DOWN event followed by a STATUS_CHANGE UP event for node2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5757) assertionError in repair
[ https://issues.apache.org/jira/browse/CASSANDRA-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711163#comment-13711163 ] Yuki Morishita edited comment on CASSANDRA-5757 at 7/17/13 3:15 PM: Hmm, the patch broke SSTableReaderTest#testGetScannerForNoIntersectionRanges. {code} java.util.NoSuchElementException at com.google.common.collect.AbstractIterator.next(AbstractIterator.java:154) at org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:169) at org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:42) at org.apache.cassandra.io.sstable.SSTableReaderTest.testGetScannerForNoIntersectingRanges(SSTableReaderTest.java:302) {code} was (Author: yukim): Hmm, the patch broke SSTableReader#testGetScannerForNoIntersectionRanges. {code} java.util.NoSuchElementException at com.google.common.collect.AbstractIterator.next(AbstractIterator.java:154) at org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:169) at org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:42) at org.apache.cassandra.io.sstable.SSTableReaderTest.testGetScannerForNoIntersectingRanges(SSTableReaderTest.java:302) {code} assertionError in repair Key: CASSANDRA-5757 URL: https://issues.apache.org/jira/browse/CASSANDRA-5757 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 2.0 beta 1 Reporter: Radim Kolar Assignee: Sylvain Lebresne Fix For: 2.0 beta 2 Attachments: 5757.txt i increased replication factor and run repair, some token ranges were repaired okay, but one failed with: INFO 13:03:52,234 [repair #dd7937a0-ebab-11e2-ba07-c38e7fba9d51] session completed successfully ERROR 13:03:52,343 Exception in thread Thread[ValidationExecutor:2,1,main] java.lang.AssertionError: (max(9099058114996150811),max(-5486100704702537010)] at org.apache.cassandra.db.DataRange.init(DataRange.java:50) at org.apache.cassandra.db.DataRange.forKeyRange(DataRange.java:74) at org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReade r.java:1033) at org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScan ners(AbstractCompactionStrategy.java:214) at org.apache.cassandra.db.compaction.CompactionManager$ValidationCompac tionIterable.init(CompactionManager.java:751) at org.apache.cassandra.db.compaction.CompactionManager.doValidationComp action(CompactionManager.java:657) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5757) assertionError in repair
[ https://issues.apache.org/jira/browse/CASSANDRA-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711163#comment-13711163 ] Yuki Morishita commented on CASSANDRA-5757: --- Hmm, the patch broke SSTableReader#testGetScannerForNoIntersectionRanges. {code} java.util.NoSuchElementException at com.google.common.collect.AbstractIterator.next(AbstractIterator.java:154) at org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:169) at org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:42) at org.apache.cassandra.io.sstable.SSTableReaderTest.testGetScannerForNoIntersectingRanges(SSTableReaderTest.java:302) {code} assertionError in repair Key: CASSANDRA-5757 URL: https://issues.apache.org/jira/browse/CASSANDRA-5757 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 2.0 beta 1 Reporter: Radim Kolar Assignee: Sylvain Lebresne Fix For: 2.0 beta 2 Attachments: 5757.txt i increased replication factor and run repair, some token ranges were repaired okay, but one failed with: INFO 13:03:52,234 [repair #dd7937a0-ebab-11e2-ba07-c38e7fba9d51] session completed successfully ERROR 13:03:52,343 Exception in thread Thread[ValidationExecutor:2,1,main] java.lang.AssertionError: (max(9099058114996150811),max(-5486100704702537010)] at org.apache.cassandra.db.DataRange.init(DataRange.java:50) at org.apache.cassandra.db.DataRange.forKeyRange(DataRange.java:74) at org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReade r.java:1033) at org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScan ners(AbstractCompactionStrategy.java:214) at org.apache.cassandra.db.compaction.CompactionManager$ValidationCompac tionIterable.init(CompactionManager.java:751) at org.apache.cassandra.db.compaction.CompactionManager.doValidationComp action(CompactionManager.java:657) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5770) Minor bugs in the native protocol v2 on 2.0.0-beta1
Sylvain Lebresne created CASSANDRA-5770: --- Summary: Minor bugs in the native protocol v2 on 2.0.0-beta1 Key: CASSANDRA-5770 URL: https://issues.apache.org/jira/browse/CASSANDRA-5770 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 2.0 beta 2 There is a few minor bugs in the new features of the native protocol. Attaching patch to fix those. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5770) Minor bugs in the native protocol v2 on 2.0.0-beta1
[ https://issues.apache.org/jira/browse/CASSANDRA-5770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5770: Attachment: 5770.txt Minor bugs in the native protocol v2 on 2.0.0-beta1 --- Key: CASSANDRA-5770 URL: https://issues.apache.org/jira/browse/CASSANDRA-5770 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 2.0 beta 2 Attachments: 5770.txt There is a few minor bugs in the new features of the native protocol. Attaching patch to fix those. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5542) BulkLoader is broken in trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-5542: -- Fix Version/s: (was: 2.0) 2.0 beta 2 BulkLoader is broken in trunk - Key: CASSANDRA-5542 URL: https://issues.apache.org/jira/browse/CASSANDRA-5542 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Yuki Morishita Assignee: Yuki Morishita Fix For: 2.0 beta 2 Attachments: 0001-change-streaming-procedure.patch, 0002-make-BulkLoader-work-with-SSTableReader.patch, 0003-update-for-post-CASSANDRA-5171.patch, 5542-fix-NPE.txt, 5542.txt After CASSANDRA-5015 and CASSANDRA-5521, we need CFMetaData to open SSTable(Reader), especially to get bloom_filter_fp_chance and index_interval. When using bulkloader, CFMetaData is not available, so we cannot open SSTable to be streamed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1
[ https://issues.apache.org/jira/browse/CASSANDRA-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-5768: --- Assignee: Brandon Williams If a Seed can't be contacted, a new node comes up as a cluster of 1 --- Key: CASSANDRA-5768 URL: https://issues.apache.org/jira/browse/CASSANDRA-5768 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Andy Cobley Assignee: Brandon Williams Priority: Minor Setting up a new test cluster using 2.0.0-beta1 and I noticed the following behaviour with vnodes turned on. I bring up one node all well and good. however if I bring up a second node, that can't contact the first (the first being the seed for the second) after a short period of time, the second goes ahead and assumes it's the only node and bootstraps with all tokens. NOTE also this email from Robert Coli To: u...@cassandra.apache.org Obviously if you have defined a seed and cannot contact it, the node should not start as a cluster of one. I have a to-do list item to file a JIRA on the subject, but if you wanted to file and link us, that'd be super. :) Startup trace (from the can't contact the seed messages below). DEBUG 17:57:46,134 Target max version is -2147483648; no version information yet, will retry INFO 17:57:46,139 Cannot handshake version with /192.168.0.10 INFO 17:57:46,147 Handshaking version with /192.168.0.10 DEBUG 17:57:51,147 Target max version is -2147483648; no version information yet, will retry INFO 17:57:51,151 Cannot handshake version with /192.168.0.10 DEBUG 17:57:51,156 attempting to connect to /192.168.0.10 INFO 17:57:51,164 Handshaking version with /192.168.0.10 DEBUG 17:57:56,163 Target max version is -2147483648; no version information yet, will retry INFO 17:57:56,168 Cannot handshake version with /192.168.0.10 INFO 17:57:56,177 Handshaking version with /192.168.0.10 DEBUG 17:58:01,176 Target max version is -2147483648; no version information yet, will retry INFO 17:58:01,195 Cannot handshake version with /192.168.0.10 DEBUG 17:58:01,199 attempting to connect to /192.168.0.10 INFO 17:58:01,211 Handshaking version with /192.168.0.10 DEBUG 17:58:06,210 Target max version is -2147483648; no version information yet, will retry INFO 17:58:06,229 Cannot handshake version with /192.168.0.10 INFO 17:58:06,243 Handshaking version with /192.168.0.10 DEBUG 17:58:11,240 Target max version is -2147483648; no version information yet, will retry INFO 17:58:11,257 Cannot handshake version with /192.168.0.10 DEBUG 17:58:11,265 attempting to connect to /192.168.0.10 DEBUG 17:58:11,249 Disseminating load info ... INFO 17:58:11,277 Handshaking version with /192.168.0.10 INFO 17:58:12,918 JOINING: Starting to bootstrap... DEBUG 17:58:12,922 Beginning bootstrap process INFO 17:58:13,065 Bootstrap completed! for the tokens [-6323000812485711377, 7540920246740048508, 8343754522398236724, 8408024349763410671, 2958176648006585896, -4558504792860463383, 6505045068820279515, -2723585437376250373, 6295277530571293136, -632036933490110017, 7076829522639601545, -972040818133908807, -8032509273357338597, -8195415716479930448, 2815056297233670800, -8514945661303914275, -1404986336850055825, 1902287316263855857, 2271127848797136099, 2253027225668615491, -4596682821656889301, -3829603337268068014, 6732451001921723049, -7525322146388049675, -7520469144418445567, -42294142306824200, -3583505036108061780, 2037651260804506174, -8857382013269212764, -287803492046061484, -2387955156962752445, 5851040736860755910, -2566990238894069943, -4862528385953509677, -6934815927114679513, 436339434870862426, -9024405707727859684, -5712896424965939691, -7306151990958768726, 1972562868127181045, 432233230504092, 3274187527528688964, -170723646511099548, -5215516480259793274, -5433009735911985650, 1611629741105319295, -1003574501709202508, -342125947698355485, -6982367747787992083, -1265530805719316699, -3787322892048394796, 4335532059375005778, -4955726035129474058, -3371084287244267978, -1356714364316547864, 2509890377680956235, -1688681099182070115, 4105757083923252042, 6251650102550794764, 6814340446137923947, 2350550282350068760, -5827526901688128468, 6417310693620297152, -3072998771907077372, -1401160349313134159, 5689378233308186158, -4579053362657493044, -1974282572872555977, 6030416333994244776, -6459751443485456668, -7053683753232252424, 3313304008102967685, -3323360202881321267, 1777100483859232105, 644078824255348160, 9174385969124367717, -3152648150979214720, -5810274955975592409, -2417697781941443512, 2097979287894624485, 1306279112226821961, -5471073413421323422, -899964525929809433,
[jira] [Updated] (CASSANDRA-5771) Small bug in Range.intersects(Bound)
[ https://issues.apache.org/jira/browse/CASSANDRA-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5771: Attachment: 5771.txt Attaching patch to fix. Small bug in Range.intersects(Bound) Key: CASSANDRA-5771 URL: https://issues.apache.org/jira/browse/CASSANDRA-5771 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.6 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.7 Attachments: 5771.txt Range.intersects(Bound) doesn't correctly handle the case where the bound in argument has the same start and end (i.e. is a Bound of 1 value). It basically always return true in that case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5757) assertionError in repair
[ https://issues.apache.org/jira/browse/CASSANDRA-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711287#comment-13711287 ] Sylvain Lebresne commented on CASSANDRA-5757: - Turns out that this is a bug in Range.intersects(Bound) that this test happens to run into. And since that bug actually affect 1.2 too, I've created CASSANDRA-5771 for that specific problem. With the patch from CASSANDRA-5771, the test passes correctly. assertionError in repair Key: CASSANDRA-5757 URL: https://issues.apache.org/jira/browse/CASSANDRA-5757 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 2.0 beta 1 Reporter: Radim Kolar Assignee: Sylvain Lebresne Fix For: 2.0 beta 2 Attachments: 5757.txt i increased replication factor and run repair, some token ranges were repaired okay, but one failed with: INFO 13:03:52,234 [repair #dd7937a0-ebab-11e2-ba07-c38e7fba9d51] session completed successfully ERROR 13:03:52,343 Exception in thread Thread[ValidationExecutor:2,1,main] java.lang.AssertionError: (max(9099058114996150811),max(-5486100704702537010)] at org.apache.cassandra.db.DataRange.init(DataRange.java:50) at org.apache.cassandra.db.DataRange.forKeyRange(DataRange.java:74) at org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReade r.java:1033) at org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScan ners(AbstractCompactionStrategy.java:214) at org.apache.cassandra.db.compaction.CompactionManager$ValidationCompac tionIterable.init(CompactionManager.java:751) at org.apache.cassandra.db.compaction.CompactionManager.doValidationComp action(CompactionManager.java:657) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1
[ https://issues.apache.org/jira/browse/CASSANDRA-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-5768: Attachment: 5768.txt It seems reasonable to me that we should ensure we've contacted a seed during bootstrap when one has been set. Patch to check for this and refuse if it fails. If a Seed can't be contacted, a new node comes up as a cluster of 1 --- Key: CASSANDRA-5768 URL: https://issues.apache.org/jira/browse/CASSANDRA-5768 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Andy Cobley Assignee: Brandon Williams Priority: Minor Attachments: 5768.txt Setting up a new test cluster using 2.0.0-beta1 and I noticed the following behaviour with vnodes turned on. I bring up one node all well and good. however if I bring up a second node, that can't contact the first (the first being the seed for the second) after a short period of time, the second goes ahead and assumes it's the only node and bootstraps with all tokens. NOTE also this email from Robert Coli To: u...@cassandra.apache.org Obviously if you have defined a seed and cannot contact it, the node should not start as a cluster of one. I have a to-do list item to file a JIRA on the subject, but if you wanted to file and link us, that'd be super. :) Startup trace (from the can't contact the seed messages below). DEBUG 17:57:46,134 Target max version is -2147483648; no version information yet, will retry INFO 17:57:46,139 Cannot handshake version with /192.168.0.10 INFO 17:57:46,147 Handshaking version with /192.168.0.10 DEBUG 17:57:51,147 Target max version is -2147483648; no version information yet, will retry INFO 17:57:51,151 Cannot handshake version with /192.168.0.10 DEBUG 17:57:51,156 attempting to connect to /192.168.0.10 INFO 17:57:51,164 Handshaking version with /192.168.0.10 DEBUG 17:57:56,163 Target max version is -2147483648; no version information yet, will retry INFO 17:57:56,168 Cannot handshake version with /192.168.0.10 INFO 17:57:56,177 Handshaking version with /192.168.0.10 DEBUG 17:58:01,176 Target max version is -2147483648; no version information yet, will retry INFO 17:58:01,195 Cannot handshake version with /192.168.0.10 DEBUG 17:58:01,199 attempting to connect to /192.168.0.10 INFO 17:58:01,211 Handshaking version with /192.168.0.10 DEBUG 17:58:06,210 Target max version is -2147483648; no version information yet, will retry INFO 17:58:06,229 Cannot handshake version with /192.168.0.10 INFO 17:58:06,243 Handshaking version with /192.168.0.10 DEBUG 17:58:11,240 Target max version is -2147483648; no version information yet, will retry INFO 17:58:11,257 Cannot handshake version with /192.168.0.10 DEBUG 17:58:11,265 attempting to connect to /192.168.0.10 DEBUG 17:58:11,249 Disseminating load info ... INFO 17:58:11,277 Handshaking version with /192.168.0.10 INFO 17:58:12,918 JOINING: Starting to bootstrap... DEBUG 17:58:12,922 Beginning bootstrap process INFO 17:58:13,065 Bootstrap completed! for the tokens [-6323000812485711377, 7540920246740048508, 8343754522398236724, 8408024349763410671, 2958176648006585896, -4558504792860463383, 6505045068820279515, -2723585437376250373, 6295277530571293136, -632036933490110017, 7076829522639601545, -972040818133908807, -8032509273357338597, -8195415716479930448, 2815056297233670800, -8514945661303914275, -1404986336850055825, 1902287316263855857, 2271127848797136099, 2253027225668615491, -4596682821656889301, -3829603337268068014, 6732451001921723049, -7525322146388049675, -7520469144418445567, -42294142306824200, -3583505036108061780, 2037651260804506174, -8857382013269212764, -287803492046061484, -2387955156962752445, 5851040736860755910, -2566990238894069943, -4862528385953509677, -6934815927114679513, 436339434870862426, -9024405707727859684, -5712896424965939691, -7306151990958768726, 1972562868127181045, 432233230504092, 3274187527528688964, -170723646511099548, -5215516480259793274, -5433009735911985650, 1611629741105319295, -1003574501709202508, -342125947698355485, -6982367747787992083, -1265530805719316699, -3787322892048394796, 4335532059375005778, -4955726035129474058, -3371084287244267978, -1356714364316547864, 2509890377680956235, -1688681099182070115, 4105757083923252042, 6251650102550794764, 6814340446137923947, 2350550282350068760, -5827526901688128468, 6417310693620297152, -3072998771907077372, -1401160349313134159, 5689378233308186158, -4579053362657493044, -1974282572872555977, 6030416333994244776, -6459751443485456668, -7053683753232252424, 3313304008102967685, -3323360202881321267, 1777100483859232105,
[jira] [Created] (CASSANDRA-5771) Small bug in Range.intersects(Bound)
Sylvain Lebresne created CASSANDRA-5771: --- Summary: Small bug in Range.intersects(Bound) Key: CASSANDRA-5771 URL: https://issues.apache.org/jira/browse/CASSANDRA-5771 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.6 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.7 Range.intersects(Bound) doesn't correctly handle the case where the bound in argument has the same start and end (i.e. is a Bound of 1 value). It basically always return true in that case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5555) Allow sstableloader to handle a larger number of files
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711349#comment-13711349 ] Jonathan Ellis commented on CASSANDRA-: --- [bump] Allow sstableloader to handle a larger number of files -- Key: CASSANDRA- URL: https://issues.apache.org/jira/browse/CASSANDRA- Project: Cassandra Issue Type: Improvement Components: Core, Tools Reporter: Tyler Hobbs Assignee: Tyler Hobbs Fix For: 1.2.7 Attachments: -01.txt, -02.txt, -2.txt, -fix-heap-and-streaming-1.2.patch, -fix-heap-and-streaming-1.2-v2.patch, cass__pic_8.png, CASSANDRA-.txt, CASSANDRA-.txt, CASSANDRA-.txt With the default heap size, sstableloader will OOM when there are roughly 25k files in the directory to load. It's easy to reach this number of files in a single LCS column family. By avoiding creating all SSTableReaders up front in SSTableLoader, we should be able to increase the number of files that sstableloader can handle considerably. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false
[ https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711351#comment-13711351 ] Jonathan Ellis commented on CASSANDRA-5704: --- Yes, it's a memtable write ... to the system.local table, with information about the truncated table. No doubt you would reply, then let's skip the flush when durable writes are disabled on the system keyspace, but you'll note that we've already special cased this flush even though the memtable writes is commitlogged -- we want it to persist immediately even with periodic commitlog mode. Truncated data reappearing is very high on the list of Behaviors That Surprise People. Therefore I propose the attached patch along the lines of what Jake and Brandon suggest, that adds a {{cassandra.unsafetruncate}} property. (Normally I am not a fan of using a 'negative' property name like 'unsafe' but I don't want to encourage people to use it, who shouldn't, which I think we risk if we use {{quicktruncate}} or similar.) Truncate flushes to disk again in 1.2, even with durable_writes=false - Key: CASSANDRA-5704 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Christian Spriegel Assignee: Christian Spriegel Priority: Minor Fix For: 1.2.7 Attachments: 5704-v2.txt, CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my JUnit tests slow again, due to a blocking-flush in saveTruncationRecord(). With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153 My proposal is to make saveTruncationRecord() only flush when durableWrites are enabled. My assumption is that if somebody turn off durable writes then he does not mind if truncate is not guaranteed to be durable either. I successfully tested the following patch with my testsuite. Its as fast as it was with 1.1 (maybe even faster!): {code} @@ -186,5 +186,8 @@ public class SystemTable String req = UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key = '%s'; processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY)); -forceBlockingFlush(LOCAL_CF); + +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name); +if (ksm.durableWrites) // flush only when durable_writes are enabled +forceBlockingFlush(LOCAL_CF); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2524) Use SSTableBoundedScanner for cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2524: -- Reviewer: jbellis (was: slebresne) Fix Version/s: (was: 2.0) 2.0.1 Assignee: Tyler Hobbs (was: Marcus Eriksson) Use SSTableBoundedScanner for cleanup - Key: CASSANDRA-2524 URL: https://issues.apache.org/jira/browse/CASSANDRA-2524 Project: Cassandra Issue Type: Improvement Reporter: Stu Hood Assignee: Tyler Hobbs Priority: Minor Labels: lhf Fix For: 2.0.1 Attachments: 0001-CASSANDRA-2524-use-SSTableBoundedScanner-for-cleanup.patch, 0001-Use-a-SSTableBoundedScanner-for-cleanup-and-improve-cl.txt, 0002-Oops.-When-indexes-or-counters-are-in-use-must-continu.txt SSTableBoundedScanner seeks rather than scanning through rows, so it would be significantly more efficient than the existing per-key filtering that cleanup does. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2524) Use SSTableBoundedScanner for cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711353#comment-13711353 ] Jonathan Ellis commented on CASSANDRA-2524: --- Assigning to Tyler since his work on CASSANDRA-5722 gets us most of the way there. Use SSTableBoundedScanner for cleanup - Key: CASSANDRA-2524 URL: https://issues.apache.org/jira/browse/CASSANDRA-2524 Project: Cassandra Issue Type: Improvement Reporter: Stu Hood Assignee: Tyler Hobbs Priority: Minor Labels: lhf Fix For: 2.0.1 Attachments: 0001-CASSANDRA-2524-use-SSTableBoundedScanner-for-cleanup.patch, 0001-Use-a-SSTableBoundedScanner-for-cleanup-and-improve-cl.txt, 0002-Oops.-When-indexes-or-counters-are-in-use-must-continu.txt SSTableBoundedScanner seeks rather than scanning through rows, so it would be significantly more efficient than the existing per-key filtering that cleanup does. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5761) Issue with secondary index sstable.
[ https://issues.apache.org/jira/browse/CASSANDRA-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711352#comment-13711352 ] Jonathan Ellis commented on CASSANDRA-5761: --- You would get that error if you are inserting empty partition keys, but we guard against that. Are you bypassing validation somehow, e.g. with json2sstable or by direct calls to StorageProxy? Issue with secondary index sstable. --- Key: CASSANDRA-5761 URL: https://issues.apache.org/jira/browse/CASSANDRA-5761 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Andriy Yevsyukov Priority: Critical With Cassandra 1.2.5 having issue very similar to [CASSANDRA-5225|https://issues.apache.org/jira/browse/CASSANDRA-5225] but for secondary index sstable. Every query that uses this index fails in Hector with ConnectionTimeout but cassandra log says that reason is: {noformat} ERROR [ReadStage:55803] 2013-07-15 12:11:35,392 CassandraDaemon.java (line 175) Exception in thread Thread[ReadStage:55803,5,main] java.lang.RuntimeException: org.apache.cassandra.io.sstable.CorruptSSTableException: org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid column name length 0 (/data/cassandra/data/betting/events/betting-events.events_sport_type_idx-ic-1-Data.db, 19658 bytes remaining) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1582) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid column name length 0 (/data/cassandra/data/betting/events/betting-events.events_sport_type_idx-ic-1-Data.db, 19658 bytes remaining) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:108) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:39) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:90) at org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:171) at org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:154) at org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:143) at org.apache.cassandra.utils.MergeIterator$ManyToOne.init(MergeIterator.java:86) at org.apache.cassandra.utils.MergeIterator.get(MergeIterator.java:45) at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:134) at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:84) at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:293) at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:65) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1357) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1214) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1126) at org.apache.cassandra.db.index.keys.KeysSearcher$1.computeNext(KeysSearcher.java:140) at org.apache.cassandra.db.index.keys.KeysSearcher$1.computeNext(KeysSearcher.java:109) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:1466) at org.apache.cassandra.db.index.keys.KeysSearcher.search(KeysSearcher.java:82) at org.apache.cassandra.db.index.SecondaryIndexManager.search(SecondaryIndexManager.java:548) at org.apache.cassandra.db.ColumnFamilyStore.search(ColumnFamilyStore.java:1454) at org.apache.cassandra.service.RangeSliceVerbHandler.executeLocally(RangeSliceVerbHandler.java:44) at org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1076) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1578) ... 3 more Caused by:
[jira] [Commented] (CASSANDRA-5722) Cleanup should skip sstables that don't contain data outside a nodes ranges
[ https://issues.apache.org/jira/browse/CASSANDRA-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711350#comment-13711350 ] Jonathan Ellis commented on CASSANDRA-5722: --- All right. I'll commit once we branch off 2.0.0; thanks. Cleanup should skip sstables that don't contain data outside a nodes ranges --- Key: CASSANDRA-5722 URL: https://issues.apache.org/jira/browse/CASSANDRA-5722 Project: Cassandra Issue Type: Improvement Reporter: Nick Bailey Assignee: Tyler Hobbs Fix For: 2.0.1 Attachments: 0001-Skip-cleanup-when-unneeded.patch Right now cleanup is optimized to simply delete sstables that *only* contain data that doesn't belong on the node, for all other sstables though, it will read them, check each row, and write out new sstables. Cleanup could be optimized to look at an sstable and determine that all data within the sstable does belong on a node, and therefore skip re-writing that sstable. This would make cleanup essentially a noop in the case where all data on a node belongs on that node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false
[ https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5704: -- Attachment: 5704-v2.txt Truncate flushes to disk again in 1.2, even with durable_writes=false - Key: CASSANDRA-5704 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Christian Spriegel Assignee: Christian Spriegel Priority: Minor Fix For: 1.2.7 Attachments: 5704-v2.txt, CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my JUnit tests slow again, due to a blocking-flush in saveTruncationRecord(). With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153 My proposal is to make saveTruncationRecord() only flush when durableWrites are enabled. My assumption is that if somebody turn off durable writes then he does not mind if truncate is not guaranteed to be durable either. I successfully tested the following patch with my testsuite. Its as fast as it was with 1.1 (maybe even faster!): {code} @@ -186,5 +186,8 @@ public class SystemTable String req = UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key = '%s'; processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY)); -forceBlockingFlush(LOCAL_CF); + +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name); +if (ksm.durableWrites) // flush only when durable_writes are enabled +forceBlockingFlush(LOCAL_CF); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5771) Small bug in Range.intersects(Bound)
[ https://issues.apache.org/jira/browse/CASSANDRA-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711380#comment-13711380 ] Jonathan Ellis commented on CASSANDRA-5771: --- +1, although I'm not sure what a punition is. Small bug in Range.intersects(Bound) Key: CASSANDRA-5771 URL: https://issues.apache.org/jira/browse/CASSANDRA-5771 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.6 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.7 Attachments: 5771.txt Range.intersects(Bound) doesn't correctly handle the case where the bound in argument has the same start and end (i.e. is a Bound of 1 value). It basically always return true in that case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-5769) Not all STATUS_CHANGE UP events reported via the native protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-5769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-5769: - Assignee: Tyler Hobbs Tyler, can you reproduce? Not all STATUS_CHANGE UP events reported via the native protocol Key: CASSANDRA-5769 URL: https://issues.apache.org/jira/browse/CASSANDRA-5769 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5, 1.2.6 Environment: Uubuntu 12.04, x86, 64 bit Reporter: Duncan Sands Assignee: Tyler Hobbs Priority: Minor Not all gossip UP events are pushed to native protocol users who have registered for them. This seems to be a native protocol issue because nodes themselves get the UP event (as seen in their logs). I can consistently reproduce this issue as follows: 1) connect a client to a cluster node (node1) using the native protocol, register for TOPOLOGY_CHANGE and STATUS_CHANGE events. (Probably you only need to register for STATUS_CHANGE to see this, however my client registers for both). 2) on another node (node2), send SIGSTOP to the Cassandra process. 3) after about 30 seconds the client gets pushed a STATUS_CHANGE DOWN event for the stopped node. 4) on node2, send SIGCONT to the the Cassandra process. 5) wait forever to get a STATUS_CHANGE UP event. This is failure: no event is ever received. Observe that node1 does know that node2 is back up: in its system log I see for example INFO [GossipStage:1] 2013-07-17 14:27:41,238 Gossiper.java (line 771) InetAddress /172.18.34.169 is now UP shortly after sending SIGCONT to the stopped process. To eliminate the possibility that my client is at fault, I performed the following sanity check: 2') on node2, stopped Cassandra nicely using: sudo service cassandra stop 4') on node2, restarted Cassandra using: sudo service cassandra start In this case the client soon after gets a STATUS_CHANGE DOWN event followed by a STATUS_CHANGE UP event for node2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1
[ https://issues.apache.org/jira/browse/CASSANDRA-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5768: -- Description: Setting up a new test cluster using 2.0.0-beta1 and I noticed the following behaviour with vnodes turned on. I bring up one node all well and good. however if I bring up a second node, that can't contact the first (the first being the seed for the second) after a short period of time, the second goes ahead and assumes it's the only node and bootstraps with all tokens. NOTE also this email from Robert Coli To: u...@cassandra.apache.org Obviously if you have defined a seed and cannot contact it, the node should not start as a cluster of one. I have a to-do list item to file a JIRA on the subject, but if you wanted to file and link us, that'd be super. :) Startup trace (from the can't contact the seed messages below). http://aep.appspot.com/display/ABcWltCES1srzPrj5CkS69-GB8o/ was: Setting up a new test cluster using 2.0.0-beta1 and I noticed the following behaviour with vnodes turned on. I bring up one node all well and good. however if I bring up a second node, that can't contact the first (the first being the seed for the second) after a short period of time, the second goes ahead and assumes it's the only node and bootstraps with all tokens. NOTE also this email from Robert Coli To: u...@cassandra.apache.org Obviously if you have defined a seed and cannot contact it, the node should not start as a cluster of one. I have a to-do list item to file a JIRA on the subject, but if you wanted to file and link us, that'd be super. :) Startup trace (from the can't contact the seed messages below). DEBUG 17:57:46,134 Target max version is -2147483648; no version information yet, will retry INFO 17:57:46,139 Cannot handshake version with /192.168.0.10 INFO 17:57:46,147 Handshaking version with /192.168.0.10 DEBUG 17:57:51,147 Target max version is -2147483648; no version information yet, will retry INFO 17:57:51,151 Cannot handshake version with /192.168.0.10 DEBUG 17:57:51,156 attempting to connect to /192.168.0.10 INFO 17:57:51,164 Handshaking version with /192.168.0.10 DEBUG 17:57:56,163 Target max version is -2147483648; no version information yet, will retry INFO 17:57:56,168 Cannot handshake version with /192.168.0.10 INFO 17:57:56,177 Handshaking version with /192.168.0.10 DEBUG 17:58:01,176 Target max version is -2147483648; no version information yet, will retry INFO 17:58:01,195 Cannot handshake version with /192.168.0.10 DEBUG 17:58:01,199 attempting to connect to /192.168.0.10 INFO 17:58:01,211 Handshaking version with /192.168.0.10 DEBUG 17:58:06,210 Target max version is -2147483648; no version information yet, will retry INFO 17:58:06,229 Cannot handshake version with /192.168.0.10 INFO 17:58:06,243 Handshaking version with /192.168.0.10 DEBUG 17:58:11,240 Target max version is -2147483648; no version information yet, will retry INFO 17:58:11,257 Cannot handshake version with /192.168.0.10 DEBUG 17:58:11,265 attempting to connect to /192.168.0.10 DEBUG 17:58:11,249 Disseminating load info ... INFO 17:58:11,277 Handshaking version with /192.168.0.10 INFO 17:58:12,918 JOINING: Starting to bootstrap... DEBUG 17:58:12,922 Beginning bootstrap process INFO 17:58:13,065 Bootstrap completed! for the tokens [-6323000812485711377, 7540920246740048508, 8343754522398236724, 8408024349763410671, 2958176648006585896, -4558504792860463383, 6505045068820279515, -2723585437376250373, 6295277530571293136, -632036933490110017, 7076829522639601545, -972040818133908807, -8032509273357338597, -8195415716479930448, 2815056297233670800, -8514945661303914275, -1404986336850055825, 1902287316263855857, 2271127848797136099, 2253027225668615491, -4596682821656889301, -3829603337268068014, 6732451001921723049, -7525322146388049675, -7520469144418445567, -42294142306824200, -3583505036108061780, 2037651260804506174, -8857382013269212764, -287803492046061484, -2387955156962752445, 5851040736860755910, -2566990238894069943, -4862528385953509677, -6934815927114679513, 436339434870862426, -9024405707727859684, -5712896424965939691, -7306151990958768726, 1972562868127181045, 432233230504092, 3274187527528688964, -170723646511099548, -5215516480259793274, -5433009735911985650, 1611629741105319295, -1003574501709202508, -342125947698355485, -6982367747787992083, -1265530805719316699, -3787322892048394796, 4335532059375005778, -4955726035129474058, -3371084287244267978, -1356714364316547864, 2509890377680956235, -1688681099182070115, 4105757083923252042, 6251650102550794764, 6814340446137923947, 2350550282350068760, -5827526901688128468, 6417310693620297152, -3072998771907077372, -1401160349313134159, 5689378233308186158, -4579053362657493044, -1974282572872555977, 6030416333994244776, -6459751443485456668,
[jira] [Commented] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false
[ https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711383#comment-13711383 ] Brandon Williams commented on CASSANDRA-5704: - +1 Truncate flushes to disk again in 1.2, even with durable_writes=false - Key: CASSANDRA-5704 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Christian Spriegel Assignee: Christian Spriegel Priority: Minor Fix For: 1.2.7 Attachments: 5704-v2.txt, CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my JUnit tests slow again, due to a blocking-flush in saveTruncationRecord(). With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153 My proposal is to make saveTruncationRecord() only flush when durableWrites are enabled. My assumption is that if somebody turn off durable writes then he does not mind if truncate is not guaranteed to be durable either. I successfully tested the following patch with my testsuite. Its as fast as it was with 1.1 (maybe even faster!): {code} @@ -186,5 +186,8 @@ public class SystemTable String req = UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key = '%s'; processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY)); -forceBlockingFlush(LOCAL_CF); + +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name); +if (ksm.durableWrites) // flush only when durable_writes are enabled +forceBlockingFlush(LOCAL_CF); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5555) Allow sstableloader to handle a larger number of files
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711405#comment-13711405 ] Tyler Hobbs commented on CASSANDRA-: Just waiting on a commit on CASSANDRA-5542 before I put in the last piece of the trunk patch. Allow sstableloader to handle a larger number of files -- Key: CASSANDRA- URL: https://issues.apache.org/jira/browse/CASSANDRA- Project: Cassandra Issue Type: Improvement Components: Core, Tools Reporter: Tyler Hobbs Assignee: Tyler Hobbs Fix For: 1.2.7 Attachments: -01.txt, -02.txt, -2.txt, -fix-heap-and-streaming-1.2.patch, -fix-heap-and-streaming-1.2-v2.patch, cass__pic_8.png, CASSANDRA-.txt, CASSANDRA-.txt, CASSANDRA-.txt With the default heap size, sstableloader will OOM when there are roughly 25k files in the directory to load. It's easy to reach this number of files in a single LCS column family. By avoiding creating all SSTableReaders up front in SSTableLoader, we should be able to increase the number of files that sstableloader can handle considerably. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5769) Not all STATUS_CHANGE UP events reported via the native protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-5769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711439#comment-13711439 ] Tyler Hobbs commented on CASSANDRA-5769: Yes, I can reliably reproduce the issue (through the python driver) with those steps using ccm. Not all STATUS_CHANGE UP events reported via the native protocol Key: CASSANDRA-5769 URL: https://issues.apache.org/jira/browse/CASSANDRA-5769 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5, 1.2.6 Environment: Uubuntu 12.04, x86, 64 bit Reporter: Duncan Sands Assignee: Tyler Hobbs Priority: Minor Not all gossip UP events are pushed to native protocol users who have registered for them. This seems to be a native protocol issue because nodes themselves get the UP event (as seen in their logs). I can consistently reproduce this issue as follows: 1) connect a client to a cluster node (node1) using the native protocol, register for TOPOLOGY_CHANGE and STATUS_CHANGE events. (Probably you only need to register for STATUS_CHANGE to see this, however my client registers for both). 2) on another node (node2), send SIGSTOP to the Cassandra process. 3) after about 30 seconds the client gets pushed a STATUS_CHANGE DOWN event for the stopped node. 4) on node2, send SIGCONT to the the Cassandra process. 5) wait forever to get a STATUS_CHANGE UP event. This is failure: no event is ever received. Observe that node1 does know that node2 is back up: in its system log I see for example INFO [GossipStage:1] 2013-07-17 14:27:41,238 Gossiper.java (line 771) InetAddress /172.18.34.169 is now UP shortly after sending SIGCONT to the stopped process. To eliminate the possibility that my client is at fault, I performed the following sanity check: 2') on node2, stopped Cassandra nicely using: sudo service cassandra stop 4') on node2, restarted Cassandra using: sudo service cassandra start In this case the client soon after gets a STATUS_CHANGE DOWN event followed by a STATUS_CHANGE UP event for node2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5772) Support streaming of SSTables created in older version's format
Yuki Morishita created CASSANDRA-5772: - Summary: Support streaming of SSTables created in older version's format Key: CASSANDRA-5772 URL: https://issues.apache.org/jira/browse/CASSANDRA-5772 Project: Cassandra Issue Type: Improvement Affects Versions: 2.0 beta 1 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Fix For: 2.0 beta 2 New streaming protocol is capable of sending and receiving older SSTables. Implement the ability to stream older versions so that we can avoid error like the one described in CASSANDRA-5104. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5772) Support streaming of SSTables created in older version's format
[ https://issues.apache.org/jira/browse/CASSANDRA-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-5772: -- Attachment: 0001-support-streaming-sstable-of-older-versions.patch Patch attached. Support streaming of SSTables created in older version's format --- Key: CASSANDRA-5772 URL: https://issues.apache.org/jira/browse/CASSANDRA-5772 Project: Cassandra Issue Type: Improvement Affects Versions: 2.0 beta 1 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Labels: streaming Fix For: 2.0 beta 2 Attachments: 0001-support-streaming-sstable-of-older-versions.patch New streaming protocol is capable of sending and receiving older SSTables. Implement the ability to stream older versions so that we can avoid error like the one described in CASSANDRA-5104. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-5769) Not all STATUS_CHANGE UP events reported via the native protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-5769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-5769: - Assignee: Sylvain Lebresne (was: Tyler Hobbs) Not all STATUS_CHANGE UP events reported via the native protocol Key: CASSANDRA-5769 URL: https://issues.apache.org/jira/browse/CASSANDRA-5769 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5, 1.2.6 Environment: Uubuntu 12.04, x86, 64 bit Reporter: Duncan Sands Assignee: Sylvain Lebresne Priority: Minor Not all gossip UP events are pushed to native protocol users who have registered for them. This seems to be a native protocol issue because nodes themselves get the UP event (as seen in their logs). I can consistently reproduce this issue as follows: 1) connect a client to a cluster node (node1) using the native protocol, register for TOPOLOGY_CHANGE and STATUS_CHANGE events. (Probably you only need to register for STATUS_CHANGE to see this, however my client registers for both). 2) on another node (node2), send SIGSTOP to the Cassandra process. 3) after about 30 seconds the client gets pushed a STATUS_CHANGE DOWN event for the stopped node. 4) on node2, send SIGCONT to the the Cassandra process. 5) wait forever to get a STATUS_CHANGE UP event. This is failure: no event is ever received. Observe that node1 does know that node2 is back up: in its system log I see for example INFO [GossipStage:1] 2013-07-17 14:27:41,238 Gossiper.java (line 771) InetAddress /172.18.34.169 is now UP shortly after sending SIGCONT to the stopped process. To eliminate the possibility that my client is at fault, I performed the following sanity check: 2') on node2, stopped Cassandra nicely using: sudo service cassandra stop 4') on node2, restarted Cassandra using: sudo service cassandra start In this case the client soon after gets a STATUS_CHANGE DOWN event followed by a STATUS_CHANGE UP event for node2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[1/3] git commit: add cassandra.unsafetruncate property patch by jbellis; reviewed by brandonwilliams for CASSANDRA-5704
Updated Branches: refs/heads/cassandra-1.2 3280fb087 - 0feb59a97 refs/heads/trunk 57f1ad3a3 - 2ef78c689 add cassandra.unsafetruncate property patch by jbellis; reviewed by brandonwilliams for CASSANDRA-5704 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0feb59a9 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0feb59a9 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0feb59a9 Branch: refs/heads/cassandra-1.2 Commit: 0feb59a97016a311989d6a7d1db0fc1ef46603fa Parents: 3280fb0 Author: Jonathan Ellis jbel...@apache.org Authored: Wed Jul 17 12:04:17 2013 -0700 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Jul 17 12:04:17 2013 -0700 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/db/SystemTable.java | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0feb59a9/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 00148a3..09f4c7b 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.2.7 + * add cassandra.unsafetruncate property (CASSANDRA-5704) * (Hadoop) quote identifiers in CqlPagingRecordReader (CASSANDRA-5763) * Add replace_node functionality for vnodes (CASSANDRA-5337) * Add timeout events to query traces (CASSANDRA-5520) http://git-wip-us.apache.org/repos/asf/cassandra/blob/0feb59a9/src/java/org/apache/cassandra/db/SystemTable.java -- diff --git a/src/java/org/apache/cassandra/db/SystemTable.java b/src/java/org/apache/cassandra/db/SystemTable.java index 187aac5..1d9fd72 100644 --- a/src/java/org/apache/cassandra/db/SystemTable.java +++ b/src/java/org/apache/cassandra/db/SystemTable.java @@ -185,7 +185,8 @@ public class SystemTable { String req = UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key = '%s'; processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY)); -forceBlockingFlush(LOCAL_CF); +if (!Boolean.getBoolean(cassandra.unsafetruncate)) +forceBlockingFlush(LOCAL_CF); } /**
[3/3] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2ef78c68 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2ef78c68 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2ef78c68 Branch: refs/heads/trunk Commit: 2ef78c689fc344f46fe7c6f12f21e490ca083da6 Parents: 57f1ad3 0feb59a Author: Jonathan Ellis jbel...@apache.org Authored: Wed Jul 17 12:05:02 2013 -0700 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Jul 17 12:05:02 2013 -0700 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/db/SystemKeyspace.java | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/2ef78c68/CHANGES.txt -- diff --cc CHANGES.txt index 09b5c25,09f4c7b..09472bc --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,89 -1,5 +1,90 @@@ +2.0.0-beta2 + * Allow nodetool with no args, and with help to run without a server (CASSANDRA-5734) + * Cleanup AbstractType/TypeSerializer classes (CASSANDRA-5744) + * Remove unimplemented cli option schema-mwt (CASSANDRA-5754) + * Support range tombstones in thrift (CASSANDRA-5435) + * Normalize table-manipulating CQL3 statements' class names (CASSANDRA-5759) + * cqlsh: add missing table options to DESCRIBE output (CASSANDRA-5749) + +2.0.0-beta1 + * Removed on-heap row cache (CASSANDRA-5348) + * use nanotime consistently for node-local timeouts (CASSANDRA-5581) + * Avoid unnecessary second pass on name-based queries (CASSANDRA-5577) + * Experimental triggers (CASSANDRA-1311) + * JEMalloc support for off-heap allocation (CASSANDRA-3997) + * Single-pass compaction (CASSANDRA-4180) + * Removed token range bisection (CASSANDRA-5518) + * Removed compatibility with pre-1.2.5 sstables and network messages + (CASSANDRA-5511) + * removed PBSPredictor (CASSANDRA-5455) + * CAS support (CASSANDRA-5062, 5441, 5442, 5443, 5619, 5667) + * Leveled compaction performs size-tiered compactions in L0 + (CASSANDRA-5371, 5439) + * Add yaml network topology snitch for mixed ec2/other envs (CASSANDRA-5339) + * Log when a node is down longer than the hint window (CASSANDRA-4554) + * Optimize tombstone creation for ExpiringColumns (CASSANDRA-4917) + * Improve LeveledScanner work estimation (CASSANDRA-5250, 5407) + * Replace compaction lock with runWithCompactionsDisabled (CASSANDRA-3430) + * Change Message IDs to ints (CASSANDRA-5307) + * Move sstable level information into the Stats component, removing the + need for a separate Manifest file (CASSANDRA-4872) + * avoid serializing to byte[] on commitlog append (CASSANDRA-5199) + * make index_interval configurable per columnfamily (CASSANDRA-3961, CASSANDRA-5650) + * add default_time_to_live (CASSANDRA-3974) + * add memtable_flush_period_in_ms (CASSANDRA-4237) + * replace supercolumns internally by composites (CASSANDRA-3237, 5123) + * upgrade thrift to 0.9.0 (CASSANDRA-3719) + * drop unnecessary keyspace parameter from user-defined compaction API + (CASSANDRA-5139) + * more robust solution to incomplete compactions + counters (CASSANDRA-5151) + * Change order of directory searching for c*.in.sh (CASSANDRA-3983) + * Add tool to reset SSTable compaction level for LCS (CASSANDRA-5271) + * Allow custom configuration loader (CASSANDRA-5045) + * Remove memory emergency pressure valve logic (CASSANDRA-3534) + * Reduce request latency with eager retry (CASSANDRA-4705) + * cqlsh: Remove ASSUME command (CASSANDRA-5331) + * Rebuild BF when loading sstables if bloom_filter_fp_chance + has changed since compaction (CASSANDRA-5015) + * remove row-level bloom filters (CASSANDRA-4885) + * Change Kernel Page Cache skipping into row preheating (disabled by default) + (CASSANDRA-4937) + * Improve repair by deciding on a gcBefore before sending + out TreeRequests (CASSANDRA-4932) + * Add an official way to disable compactions (CASSANDRA-5074) + * Reenable ALTER TABLE DROP with new semantics (CASSANDRA-3919) + * Add binary protocol versioning (CASSANDRA-5436) + * Swap THshaServer for TThreadedSelectorServer (CASSANDRA-5530) + * Add alias support to SELECT statement (CASSANDRA-5075) + * Don't create empty RowMutations in CommitLogReplayer (CASSANDRA-5541) + * Use range tombstones when dropping cfs/columns from schema (CASSANDRA-5579) + * cqlsh: drop CQL2/CQL3-beta support (CASSANDRA-5585) + * Track max/min column names in sstables to be able to optimize slice + queries (CASSANDRA-5514, CASSANDRA-5595, CASSANDRA-5600) + * Binary protocol: allow batching already prepared statements (CASSANDRA-4693) + * Allow preparing timestamp, ttl and limit in CQL3 queries (CASSANDRA-4450) +
[2/3] git commit: add cassandra.unsafetruncate property patch by jbellis; reviewed by brandonwilliams for CASSANDRA-5704
add cassandra.unsafetruncate property patch by jbellis; reviewed by brandonwilliams for CASSANDRA-5704 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0feb59a9 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0feb59a9 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0feb59a9 Branch: refs/heads/trunk Commit: 0feb59a97016a311989d6a7d1db0fc1ef46603fa Parents: 3280fb0 Author: Jonathan Ellis jbel...@apache.org Authored: Wed Jul 17 12:04:17 2013 -0700 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Jul 17 12:04:17 2013 -0700 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/db/SystemTable.java | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0feb59a9/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 00148a3..09f4c7b 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.2.7 + * add cassandra.unsafetruncate property (CASSANDRA-5704) * (Hadoop) quote identifiers in CqlPagingRecordReader (CASSANDRA-5763) * Add replace_node functionality for vnodes (CASSANDRA-5337) * Add timeout events to query traces (CASSANDRA-5520) http://git-wip-us.apache.org/repos/asf/cassandra/blob/0feb59a9/src/java/org/apache/cassandra/db/SystemTable.java -- diff --git a/src/java/org/apache/cassandra/db/SystemTable.java b/src/java/org/apache/cassandra/db/SystemTable.java index 187aac5..1d9fd72 100644 --- a/src/java/org/apache/cassandra/db/SystemTable.java +++ b/src/java/org/apache/cassandra/db/SystemTable.java @@ -185,7 +185,8 @@ public class SystemTable { String req = UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key = '%s'; processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY)); -forceBlockingFlush(LOCAL_CF); +if (!Boolean.getBoolean(cassandra.unsafetruncate)) +forceBlockingFlush(LOCAL_CF); } /**
[jira] [Updated] (CASSANDRA-5770) Minor bugs in the native protocol v2 on 2.0.0-beta1
[ https://issues.apache.org/jira/browse/CASSANDRA-5770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5770: -- Reviewer: iamaleksey Minor bugs in the native protocol v2 on 2.0.0-beta1 --- Key: CASSANDRA-5770 URL: https://issues.apache.org/jira/browse/CASSANDRA-5770 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 2.0 beta 2 Attachments: 5770.txt There is a few minor bugs in the new features of the native protocol. Attaching patch to fix those. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5773) print cluster name in describe cluster
Philip Crotwell created CASSANDRA-5773: -- Summary: print cluster name in describe cluster Key: CASSANDRA-5773 URL: https://issues.apache.org/jira/browse/CASSANDRA-5773 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.6 Reporter: Philip Crotwell Assignee: Philip Crotwell Priority: Trivial Would be nice to print the cluster name when doing 'describe cluster' in cassandra-cli. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5773) print cluster name in describe cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Crotwell updated CASSANDRA-5773: --- Attachment: trunk-5773.txt Patch print cluster name in describe cluster -- Key: CASSANDRA-5773 URL: https://issues.apache.org/jira/browse/CASSANDRA-5773 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.6 Reporter: Philip Crotwell Assignee: Philip Crotwell Priority: Trivial Attachments: trunk-5773.txt Would be nice to print the cluster name when doing 'describe cluster' in cassandra-cli. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (CASSANDRA-5773) print cluster name in describe cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Crotwell updated CASSANDRA-5773: --- Comment: was deleted (was: Patch) print cluster name in describe cluster -- Key: CASSANDRA-5773 URL: https://issues.apache.org/jira/browse/CASSANDRA-5773 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.6 Reporter: Philip Crotwell Assignee: Philip Crotwell Priority: Trivial Attachments: trunk-5773.txt Would be nice to print the cluster name when doing 'describe cluster' in cassandra-cli. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5774) Fix system.schema_triggers-related trigger/schema issues
Aleksey Yeschenko created CASSANDRA-5774: Summary: Fix system.schema_triggers-related trigger/schema issues Key: CASSANDRA-5774 URL: https://issues.apache.org/jira/browse/CASSANDRA-5774 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Priority: Minor Fix For: 2.0 beta 2 Attachments: 5774.txt Among other things, the patch does the following: - adds missing schema_triggers to MigrationManager.resetLocalSchema() - adds missing schema_triggers to SystemKeyspace.serializeSchema() - so that triggers would be part of schema version calculation - adds missing schema_triggers to DefsTables.flushSchemaCFs() - adds missing triggers to CFMetaData.toSchema(), so that CFs created via thrift with triggers from the beginning would serialize triggers - removes triggers from CFMetaData.newIndexMetadata(), so that 2i CFs wouldn't inherit the triggers from the parent CF There are other minor and not so minor changes, but these were the most critical ones. The patch also (unnecessarily) cleans up ColumnDefinition, but that was done to make it consistent with the new TriggerDefinition class. The bulk of the patch is the updated thrift-gen files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5774) Fix system.schema_triggers-related trigger/schema issues
[ https://issues.apache.org/jira/browse/CASSANDRA-5774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5774: - Attachment: 5774.txt Fix system.schema_triggers-related trigger/schema issues Key: CASSANDRA-5774 URL: https://issues.apache.org/jira/browse/CASSANDRA-5774 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Priority: Minor Labels: triggers Fix For: 2.0 beta 2 Attachments: 5774.txt Among other things, the patch does the following: - adds missing schema_triggers to MigrationManager.resetLocalSchema() - adds missing schema_triggers to SystemKeyspace.serializeSchema() - so that triggers would be part of schema version calculation - adds missing schema_triggers to DefsTables.flushSchemaCFs() - adds missing triggers to CFMetaData.toSchema(), so that CFs created via thrift with triggers from the beginning would serialize triggers - removes triggers from CFMetaData.newIndexMetadata(), so that 2i CFs wouldn't inherit the triggers from the parent CF There are other minor and not so minor changes, but these were the most critical ones. The patch also (unnecessarily) cleans up ColumnDefinition, but that was done to make it consistent with the new TriggerDefinition class. The bulk of the patch is the updated thrift-gen files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[1/3] git commit: Print cluster name in describe cluster. Patch by Philip Crotwell, reviewed by brandonwilliams for CASSANDRA-5773
Updated Branches: refs/heads/cassandra-1.2 0feb59a97 - 9382c4b4c refs/heads/trunk 2ef78c689 - 09d3d2b83 Print cluster name in describe cluster. Patch by Philip Crotwell, reviewed by brandonwilliams for CASSANDRA-5773 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9382c4b4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9382c4b4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9382c4b4 Branch: refs/heads/cassandra-1.2 Commit: 9382c4b4c505f89ad23df0455ea0c7001317eb3c Parents: 0feb59a Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Jul 17 15:01:37 2013 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Jul 17 15:01:37 2013 -0500 -- src/java/org/apache/cassandra/cli/CliClient.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9382c4b4/src/java/org/apache/cassandra/cli/CliClient.java -- diff --git a/src/java/org/apache/cassandra/cli/CliClient.java b/src/java/org/apache/cassandra/cli/CliClient.java index 9209b87..6857aea 100644 --- a/src/java/org/apache/cassandra/cli/CliClient.java +++ b/src/java/org/apache/cassandra/cli/CliClient.java @@ -2312,6 +2312,7 @@ public class CliClient sessionState.out.println(Cluster Information:); try { +sessionState.out.println( Name: + thriftClient.describe_cluster_name()); sessionState.out.println( Snitch: + thriftClient.describe_snitch()); sessionState.out.println( Partitioner: + thriftClient.describe_partitioner());
[3/3] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/09d3d2b8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/09d3d2b8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/09d3d2b8 Branch: refs/heads/trunk Commit: 09d3d2b839172c37bd2a6605ff29bfbcb1d735bb Parents: 2ef78c6 9382c4b Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Jul 17 15:02:42 2013 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Jul 17 15:02:42 2013 -0500 -- src/java/org/apache/cassandra/cli/CliClient.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/09d3d2b8/src/java/org/apache/cassandra/cli/CliClient.java --
[2/3] git commit: Print cluster name in describe cluster. Patch by Philip Crotwell, reviewed by brandonwilliams for CASSANDRA-5773
Print cluster name in describe cluster. Patch by Philip Crotwell, reviewed by brandonwilliams for CASSANDRA-5773 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9382c4b4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9382c4b4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9382c4b4 Branch: refs/heads/trunk Commit: 9382c4b4c505f89ad23df0455ea0c7001317eb3c Parents: 0feb59a Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Jul 17 15:01:37 2013 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Jul 17 15:01:37 2013 -0500 -- src/java/org/apache/cassandra/cli/CliClient.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9382c4b4/src/java/org/apache/cassandra/cli/CliClient.java -- diff --git a/src/java/org/apache/cassandra/cli/CliClient.java b/src/java/org/apache/cassandra/cli/CliClient.java index 9209b87..6857aea 100644 --- a/src/java/org/apache/cassandra/cli/CliClient.java +++ b/src/java/org/apache/cassandra/cli/CliClient.java @@ -2312,6 +2312,7 @@ public class CliClient sessionState.out.println(Cluster Information:); try { +sessionState.out.println( Name: + thriftClient.describe_cluster_name()); sessionState.out.println( Snitch: + thriftClient.describe_snitch()); sessionState.out.println( Partitioner: + thriftClient.describe_partitioner());
[jira] [Commented] (CASSANDRA-5555) Allow sstableloader to handle a larger number of files
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711552#comment-13711552 ] Alex Zarutin commented on CASSANDRA-: - Is it going to trunk or cassandra-1.2? Allow sstableloader to handle a larger number of files -- Key: CASSANDRA- URL: https://issues.apache.org/jira/browse/CASSANDRA- Project: Cassandra Issue Type: Improvement Components: Core, Tools Reporter: Tyler Hobbs Assignee: Tyler Hobbs Fix For: 1.2.7 Attachments: -01.txt, -02.txt, -2.txt, -fix-heap-and-streaming-1.2.patch, -fix-heap-and-streaming-1.2-v2.patch, cass__pic_8.png, CASSANDRA-.txt, CASSANDRA-.txt, CASSANDRA-.txt With the default heap size, sstableloader will OOM when there are roughly 25k files in the directory to load. It's easy to reach this number of files in a single LCS column family. By avoiding creating all SSTableReaders up front in SSTableLoader, we should be able to increase the number of files that sstableloader can handle considerably. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5542) BulkLoader is broken in trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-5542: -- Attachment: (was: 0001-change-streaming-procedure.patch) BulkLoader is broken in trunk - Key: CASSANDRA-5542 URL: https://issues.apache.org/jira/browse/CASSANDRA-5542 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Yuki Morishita Assignee: Yuki Morishita Fix For: 2.0 beta 2 Attachments: 0002-make-BulkLoader-work-with-SSTableReader.patch, 0003-update-for-post-CASSANDRA-5171.patch, 5542-fix-NPE.txt, 5542.txt After CASSANDRA-5015 and CASSANDRA-5521, we need CFMetaData to open SSTable(Reader), especially to get bloom_filter_fp_chance and index_interval. When using bulkloader, CFMetaData is not available, so we cannot open SSTable to be streamed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5542) BulkLoader is broken in trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-5542: -- Attachment: 0001-change-streaming-procedure.patch Thanks for the review. Updated 0001 patch. bq. Does separating initiated and receiving stream in StreamManager really buys us anything? (outside slightly complicating things) We need to keep StreamResultFuture of the same plan ID when we are doing streaming on the same JVM. This happens when we bulk load via JMX method, or running StreamingTransferTest unit test. bq. On failure (StreamSession.onError), we could (and probably should) send a message as long as the outgoing connection is opened (even if the incoming one is broken), so the current isConnected() is possibly a bit restrictive. You are right. I changed to put null check on outgoing message handler before sending message instead. BulkLoader is broken in trunk - Key: CASSANDRA-5542 URL: https://issues.apache.org/jira/browse/CASSANDRA-5542 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Yuki Morishita Assignee: Yuki Morishita Fix For: 2.0 beta 2 Attachments: 0001-change-streaming-procedure.patch, 0002-make-BulkLoader-work-with-SSTableReader.patch, 0003-update-for-post-CASSANDRA-5171.patch, 5542-fix-NPE.txt, 5542.txt After CASSANDRA-5015 and CASSANDRA-5521, we need CFMetaData to open SSTable(Reader), especially to get bloom_filter_fp_chance and index_interval. When using bulkloader, CFMetaData is not available, so we cannot open SSTable to be streamed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5746) HHOM.countPendingHints is a trap for the unwary
[ https://issues.apache.org/jira/browse/CASSANDRA-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs updated CASSANDRA-5746: --- Attachment: 0002-Report-created-hint-count-by-endpoint.patch 0001-Remove-HHOM.countPendingHints.patch 0001 removes countPendingHints(). 0002 adds a per-endpoint count through the new metrics system. I made HHOM.hintFor() non-static, as I couldn't see why the singleton couldn't be used. Let me know if there was some motivation for that. HHOM.countPendingHints is a trap for the unwary --- Key: CASSANDRA-5746 URL: https://issues.apache.org/jira/browse/CASSANDRA-5746 Project: Cassandra Issue Type: Bug Components: Core, Tools Reporter: Jonathan Ellis Assignee: Tyler Hobbs Fix For: 2.0 beta 2 Attachments: 0001-Remove-HHOM.countPendingHints.patch, 0002-Report-created-hint-count-by-endpoint.patch countPendingHints can OOM the server fairly easily since it does a per-target seq scan without paging. More generally, countPendingHints is far too slow to be useful for routine monitoring. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5555) Allow sstableloader to handle a larger number of files
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711640#comment-13711640 ] Jonathan Ellis commented on CASSANDRA-: --- Yes. Allow sstableloader to handle a larger number of files -- Key: CASSANDRA- URL: https://issues.apache.org/jira/browse/CASSANDRA- Project: Cassandra Issue Type: Improvement Components: Core, Tools Reporter: Tyler Hobbs Assignee: Tyler Hobbs Fix For: 1.2.7 Attachments: -01.txt, -02.txt, -2.txt, -fix-heap-and-streaming-1.2.patch, -fix-heap-and-streaming-1.2-v2.patch, cass__pic_8.png, CASSANDRA-.txt, CASSANDRA-.txt, CASSANDRA-.txt With the default heap size, sstableloader will OOM when there are roughly 25k files in the directory to load. It's easy to reach this number of files in a single LCS column family. By avoiding creating all SSTableReaders up front in SSTableLoader, we should be able to increase the number of files that sstableloader can handle considerably. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5752) Thrift tables are not supported from CqlPagingInputFormat
[ https://issues.apache.org/jira/browse/CASSANDRA-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-5752: Attachment: 5752-1-1.2-branch.txt 5752-1-1.2-branch.txt is attached. It doesn't use exception any more Thrift tables are not supported from CqlPagingInputFormat - Key: CASSANDRA-5752 URL: https://issues.apache.org/jira/browse/CASSANDRA-5752 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.2.6 Reporter: Jonathan Ellis Assignee: Alex Liu Fix For: 1.2.7 Attachments: 5752-1-1.2-branch.txt, 5752-1.2-branch.txt CqlPagingInputFormat inspects the system schema to generate the WHERE clauses needed to page wide rows, but for a classic Thrift table there are no entries for the default column names of key, column1, column2, ..., value so CPIF breaks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false
[ https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711787#comment-13711787 ] Christian Spriegel commented on CASSANDRA-5704: --- [~jbellis], [~brandon.williams]: I'm fine with a property. Thanks! Is there any chance we can make it a cassandra.unsafesystem-property and apply the same behaviour to all system table operations? This would then also speed up schema changes, which are are also a pain for tests. FWIW: I attached a patch which works nicely for me. Truncate flushes to disk again in 1.2, even with durable_writes=false - Key: CASSANDRA-5704 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Christian Spriegel Assignee: Jonathan Ellis Priority: Minor Fix For: 1.2.7, 2.0 beta 2 Attachments: 5704_unsafeSystem.txt, 5704-v2.txt, CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my JUnit tests slow again, due to a blocking-flush in saveTruncationRecord(). With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153 My proposal is to make saveTruncationRecord() only flush when durableWrites are enabled. My assumption is that if somebody turn off durable writes then he does not mind if truncate is not guaranteed to be durable either. I successfully tested the following patch with my testsuite. Its as fast as it was with 1.1 (maybe even faster!): {code} @@ -186,5 +186,8 @@ public class SystemTable String req = UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key = '%s'; processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY)); -forceBlockingFlush(LOCAL_CF); + +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name); +if (ksm.durableWrites) // flush only when durable_writes are enabled +forceBlockingFlush(LOCAL_CF); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false
[ https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Spriegel updated CASSANDRA-5704: -- Attachment: 5704_unsafeSystem.txt Truncate flushes to disk again in 1.2, even with durable_writes=false - Key: CASSANDRA-5704 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Christian Spriegel Assignee: Jonathan Ellis Priority: Minor Fix For: 1.2.7, 2.0 beta 2 Attachments: 5704_unsafeSystem.txt, 5704-v2.txt, CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my JUnit tests slow again, due to a blocking-flush in saveTruncationRecord(). With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153 My proposal is to make saveTruncationRecord() only flush when durableWrites are enabled. My assumption is that if somebody turn off durable writes then he does not mind if truncate is not guaranteed to be durable either. I successfully tested the following patch with my testsuite. Its as fast as it was with 1.1 (maybe even faster!): {code} @@ -186,5 +186,8 @@ public class SystemTable String req = UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key = '%s'; processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY)); -forceBlockingFlush(LOCAL_CF); + +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name); +if (ksm.durableWrites) // flush only when durable_writes are enabled +forceBlockingFlush(LOCAL_CF); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false
[ https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711787#comment-13711787 ] Christian Spriegel edited comment on CASSANDRA-5704 at 7/17/13 11:23 PM: - [~jbellis], [~brandon.williams]: I'm fine with a property. Thanks! Is there any chance we can make it a cassandra.unsafesystem-property and apply the same behaviour to all system table operations? This would then also speed up schema changes, which are are also a pain for tests. FWIW: I attached a patch which works nicely for me. Update: Perhaps as a separate 2.0 ticket? was (Author: christianmovi): [~jbellis], [~brandon.williams]: I'm fine with a property. Thanks! Is there any chance we can make it a cassandra.unsafesystem-property and apply the same behaviour to all system table operations? This would then also speed up schema changes, which are are also a pain for tests. FWIW: I attached a patch which works nicely for me. Truncate flushes to disk again in 1.2, even with durable_writes=false - Key: CASSANDRA-5704 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Christian Spriegel Assignee: Jonathan Ellis Priority: Minor Fix For: 1.2.7, 2.0 beta 2 Attachments: 5704_unsafeSystem.txt, 5704-v2.txt, CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my JUnit tests slow again, due to a blocking-flush in saveTruncationRecord(). With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153 My proposal is to make saveTruncationRecord() only flush when durableWrites are enabled. My assumption is that if somebody turn off durable writes then he does not mind if truncate is not guaranteed to be durable either. I successfully tested the following patch with my testsuite. Its as fast as it was with 1.1 (maybe even faster!): {code} @@ -186,5 +186,8 @@ public class SystemTable String req = UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key = '%s'; processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY)); -forceBlockingFlush(LOCAL_CF); + +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name); +if (ksm.durableWrites) // flush only when durable_writes are enabled +forceBlockingFlush(LOCAL_CF); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: StorageService.getPartitioner is a static method
Updated Branches: refs/heads/trunk 09d3d2b83 - 2b53cf78f StorageService.getPartitioner is a static method Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2b53cf78 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2b53cf78 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2b53cf78 Branch: refs/heads/trunk Commit: 2b53cf78f53b333f90f0b3d55e209483d0434f75 Parents: 09d3d2b Author: Dave Brosius dbros...@apache.org Authored: Wed Jul 17 22:36:24 2013 -0400 Committer: Dave Brosius dbros...@apache.org Committed: Wed Jul 17 22:36:24 2013 -0400 -- src/java/org/apache/cassandra/cql3/functions/TokenFct.java | 2 +- src/java/org/apache/cassandra/service/StorageProxy.java| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b53cf78/src/java/org/apache/cassandra/cql3/functions/TokenFct.java -- diff --git a/src/java/org/apache/cassandra/cql3/functions/TokenFct.java b/src/java/org/apache/cassandra/cql3/functions/TokenFct.java index 21695ca..69e2bf4 100644 --- a/src/java/org/apache/cassandra/cql3/functions/TokenFct.java +++ b/src/java/org/apache/cassandra/cql3/functions/TokenFct.java @@ -32,7 +32,7 @@ import org.apache.cassandra.service.StorageService; public class TokenFct extends AbstractFunction { // The actual token function depends on the partitioner used -private static final IPartitioner partitioner = StorageService.instance.getPartitioner(); +private static final IPartitioner partitioner = StorageService.getPartitioner(); public static final Function.Factory factory = new Function.Factory() { http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b53cf78/src/java/org/apache/cassandra/service/StorageProxy.java -- diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java b/src/java/org/apache/cassandra/service/StorageProxy.java index ee1e29a..3b5b69e 100644 --- a/src/java/org/apache/cassandra/service/StorageProxy.java +++ b/src/java/org/apache/cassandra/service/StorageProxy.java @@ -1333,7 +1333,7 @@ public class StorageProxy implements StorageProxyMBean public static ListInetAddress getLiveSortedEndpoints(Keyspace keyspace, ByteBuffer key) { -return getLiveSortedEndpoints(keyspace, StorageService.instance.getPartitioner().decorateKey(key)); +return getLiveSortedEndpoints(keyspace, StorageService.getPartitioner().decorateKey(key)); } private static ListInetAddress getLiveSortedEndpoints(Keyspace keyspace, RingPosition pos)
[jira] [Commented] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1
[ https://issues.apache.org/jira/browse/CASSANDRA-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13712030#comment-13712030 ] Jason Brown commented on CASSANDRA-5768: lgtm. One (incredibly minor) optimization in Gossiper.checkSeedContact() would be to check the boolean before checking the map for the seed ep, like this: {code}protected void checkSeedContact(InetAddress ep) { if (!seedContacted seeds.contains(ep)) seedContacted = true; } {code} It could be that the effort of me writing this comment is greater than the grand sum of all processing time saved by this optimization, but what the hell :). If a Seed can't be contacted, a new node comes up as a cluster of 1 --- Key: CASSANDRA-5768 URL: https://issues.apache.org/jira/browse/CASSANDRA-5768 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Andy Cobley Assignee: Brandon Williams Priority: Minor Fix For: 2.0 beta 2 Attachments: 5768.txt Setting up a new test cluster using 2.0.0-beta1 and I noticed the following behaviour with vnodes turned on. I bring up one node all well and good. however if I bring up a second node, that can't contact the first (the first being the seed for the second) after a short period of time, the second goes ahead and assumes it's the only node and bootstraps with all tokens. NOTE also this email from Robert Coli To: u...@cassandra.apache.org Obviously if you have defined a seed and cannot contact it, the node should not start as a cluster of one. I have a to-do list item to file a JIRA on the subject, but if you wanted to file and link us, that'd be super. :) Startup trace (from the can't contact the seed messages below). http://aep.appspot.com/display/ABcWltCES1srzPrj5CkS69-GB8o/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1
[ https://issues.apache.org/jira/browse/CASSANDRA-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13712031#comment-13712031 ] Jason Brown commented on CASSANDRA-5768: Also, is there any harm in adding this to 1.2? Seems rather innocuous, I think. If a Seed can't be contacted, a new node comes up as a cluster of 1 --- Key: CASSANDRA-5768 URL: https://issues.apache.org/jira/browse/CASSANDRA-5768 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Andy Cobley Assignee: Brandon Williams Priority: Minor Fix For: 2.0 beta 2 Attachments: 5768.txt Setting up a new test cluster using 2.0.0-beta1 and I noticed the following behaviour with vnodes turned on. I bring up one node all well and good. however if I bring up a second node, that can't contact the first (the first being the seed for the second) after a short period of time, the second goes ahead and assumes it's the only node and bootstraps with all tokens. NOTE also this email from Robert Coli To: u...@cassandra.apache.org Obviously if you have defined a seed and cannot contact it, the node should not start as a cluster of one. I have a to-do list item to file a JIRA on the subject, but if you wanted to file and link us, that'd be super. :) Startup trace (from the can't contact the seed messages below). http://aep.appspot.com/display/ABcWltCES1srzPrj5CkS69-GB8o/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira