[jira] [Commented] (CASSANDRA-1337) parallelize fetching rows for low-cardinality indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398222#comment-13398222 ] Vijay commented on CASSANDRA-1337: -- Agree, and +1 for the rebased version of the patch. David, let me know if you have anything in addition to the attached. parallelize fetching rows for low-cardinality indexes - Key: CASSANDRA-1337 URL: https://issues.apache.org/jira/browse/CASSANDRA-1337 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 0001-CASSANDRA-1337-scan-concurrently-depending-on-num-rows.txt, CASSANDRA-1337.patch Original Estimate: 8h Remaining Estimate: 8h currently, we read the indexed rows from the first node (in partitioner order); if that does not have enough matching rows, we read the rows from the next, and so forth. we should use the statistics fom CASSANDRA-1155 to query multiple nodes in parallel, such that we have a high chance of getting enough rows w/o having to do another round of queries (but, if our estimate is incorrect, we do need to loop and do more rounds until we have enough data or we have fetched from each node). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2986) Fix short reads in range (and index?) scans
[ https://issues.apache.org/jira/browse/CASSANDRA-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2986: -- Assignee: David Alves Fix short reads in range (and index?) scans --- Key: CASSANDRA-2986 URL: https://issues.apache.org/jira/browse/CASSANDRA-2986 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2 See CASSANDRA-2643 for the [multi]get fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4321) stackoverflow building interval tree possible sstable corruptions
[ https://issues.apache.org/jira/browse/CASSANDRA-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4321: Attachment: (was: 0003-Create-standalone-scrub-v5.txt) stackoverflow building interval tree possible sstable corruptions --- Key: CASSANDRA-4321 URL: https://issues.apache.org/jira/browse/CASSANDRA-4321 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Reporter: Anton Winter Assignee: Sylvain Lebresne Fix For: 1.1.2 Attachments: 0001-Change-Range-Bounds-in-LeveledManifest.overlapping-v5.txt, 0002-Scrub-detects-and-repair-outOfOrder-rows-v5.txt, 0003-Create-standalone-scrub-v5.txt, ooyala-hastur-stacktrace.txt After upgrading to 1.1.1 (from 1.1.0) I have started experiencing StackOverflowError's resulting in compaction backlog and failure to restart. The ring currently consists of 6 DC's and 22 nodes using LCS compression. This issue was first noted on 2 nodes in one DC and then appears to have spread to various other nodes in the other DC's. When the first occurrence of this was found I restarted the instance but it failed to start so I cleared its data and treated it as a replacement node for the token it was previously responsible for. This node successfully streamed all the relevant data back but failed again a number of hours later with the same StackOverflowError and again was unable to restart. The initial stack overflow error on a running instance looks like this: ERROR [CompactionExecutor:314] 2012-06-07 09:59:43,017 AbstractCassandraDaemon.java (line 134) Exception in thread Thread[CompactionExecutor:314,1,main] java.lang.StackOverflowError at java.util.Arrays.mergeSort(Arrays.java:1157) at java.util.Arrays.sort(Arrays.java:1092) at java.util.Collections.sort(Collections.java:134) at org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:114) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:49) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) [snip - this repeats until stack overflow. Compactions stop from this point onwards] I restarted this failing instance with DEBUG logging enabled and it throws the following exception part way through startup: ERROR 11:37:51,046 Exception in thread Thread[OptionalTasks:1,5,main] java.lang.StackOverflowError at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:307) at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276) at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230) at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124) at org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:228) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:45) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) [snip - this repeats until stack overflow] at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalTree.init(IntervalTree.java:39) at org.apache.cassandra.db.DataTracker.buildIntervalTree(DataTracker.java:560) at org.apache.cassandra.db.DataTracker$View.replace(DataTracker.java:617)
[jira] [Updated] (CASSANDRA-4321) stackoverflow building interval tree possible sstable corruptions
[ https://issues.apache.org/jira/browse/CASSANDRA-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4321: Attachment: 0003-Create-standalone-scrub-v5.txt stackoverflow building interval tree possible sstable corruptions --- Key: CASSANDRA-4321 URL: https://issues.apache.org/jira/browse/CASSANDRA-4321 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Reporter: Anton Winter Assignee: Sylvain Lebresne Fix For: 1.1.2 Attachments: 0001-Change-Range-Bounds-in-LeveledManifest.overlapping-v5.txt, 0002-Scrub-detects-and-repair-outOfOrder-rows-v5.txt, 0003-Create-standalone-scrub-v5.txt, ooyala-hastur-stacktrace.txt After upgrading to 1.1.1 (from 1.1.0) I have started experiencing StackOverflowError's resulting in compaction backlog and failure to restart. The ring currently consists of 6 DC's and 22 nodes using LCS compression. This issue was first noted on 2 nodes in one DC and then appears to have spread to various other nodes in the other DC's. When the first occurrence of this was found I restarted the instance but it failed to start so I cleared its data and treated it as a replacement node for the token it was previously responsible for. This node successfully streamed all the relevant data back but failed again a number of hours later with the same StackOverflowError and again was unable to restart. The initial stack overflow error on a running instance looks like this: ERROR [CompactionExecutor:314] 2012-06-07 09:59:43,017 AbstractCassandraDaemon.java (line 134) Exception in thread Thread[CompactionExecutor:314,1,main] java.lang.StackOverflowError at java.util.Arrays.mergeSort(Arrays.java:1157) at java.util.Arrays.sort(Arrays.java:1092) at java.util.Collections.sort(Collections.java:134) at org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:114) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:49) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) [snip - this repeats until stack overflow. Compactions stop from this point onwards] I restarted this failing instance with DEBUG logging enabled and it throws the following exception part way through startup: ERROR 11:37:51,046 Exception in thread Thread[OptionalTasks:1,5,main] java.lang.StackOverflowError at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:307) at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276) at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230) at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124) at org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:228) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:45) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) [snip - this repeats until stack overflow] at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalTree.init(IntervalTree.java:39) at org.apache.cassandra.db.DataTracker.buildIntervalTree(DataTracker.java:560) at org.apache.cassandra.db.DataTracker$View.replace(DataTracker.java:617) at
[jira] [Commented] (CASSANDRA-4321) stackoverflow building interval tree possible sstable corruptions
[ https://issues.apache.org/jira/browse/CASSANDRA-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398326#comment-13398326 ] Sylvain Lebresne commented on CASSANDRA-4321: - bq. The above error is due to the %d in StandaloneScrubber.java:179's interpolation. Yes, sorry for that typo. I've updated the v5 patch to fix it. bq. Got java.lang.OutOfMemoryError: Java heap space with -Xmx256M The last version of the offline scrub loads all sstable readers, which means in particular that it loads the summary of the key index and the sstable bloom filter. In other words, it does use a bit more memory, so it's not necessarily surprising that -Xmx256M is not enough. bq. LeveledCompactionStrategyTest:testValidationMultipleSSTablePerLevel fails because of junit timeout when I run it together with all other suits, but passes when I only run LeveledCompactionStrategyTest suit. Is it related? I doubt it. I've already seen test timeout when run with the full suit but not alone. I wouldn't worry too much about that. At least that test is working fine on my machine. stackoverflow building interval tree possible sstable corruptions --- Key: CASSANDRA-4321 URL: https://issues.apache.org/jira/browse/CASSANDRA-4321 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Reporter: Anton Winter Assignee: Sylvain Lebresne Fix For: 1.1.2 Attachments: 0001-Change-Range-Bounds-in-LeveledManifest.overlapping-v5.txt, 0002-Scrub-detects-and-repair-outOfOrder-rows-v5.txt, 0003-Create-standalone-scrub-v5.txt, ooyala-hastur-stacktrace.txt After upgrading to 1.1.1 (from 1.1.0) I have started experiencing StackOverflowError's resulting in compaction backlog and failure to restart. The ring currently consists of 6 DC's and 22 nodes using LCS compression. This issue was first noted on 2 nodes in one DC and then appears to have spread to various other nodes in the other DC's. When the first occurrence of this was found I restarted the instance but it failed to start so I cleared its data and treated it as a replacement node for the token it was previously responsible for. This node successfully streamed all the relevant data back but failed again a number of hours later with the same StackOverflowError and again was unable to restart. The initial stack overflow error on a running instance looks like this: ERROR [CompactionExecutor:314] 2012-06-07 09:59:43,017 AbstractCassandraDaemon.java (line 134) Exception in thread Thread[CompactionExecutor:314,1,main] java.lang.StackOverflowError at java.util.Arrays.mergeSort(Arrays.java:1157) at java.util.Arrays.sort(Arrays.java:1092) at java.util.Collections.sort(Collections.java:134) at org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:114) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:49) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) [snip - this repeats until stack overflow. Compactions stop from this point onwards] I restarted this failing instance with DEBUG logging enabled and it throws the following exception part way through startup: ERROR 11:37:51,046 Exception in thread Thread[OptionalTasks:1,5,main] java.lang.StackOverflowError at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:307) at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276) at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230) at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124) at org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:228) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:45) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) [snip - this repeats until stack overflow] at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at
[jira] [Created] (CASSANDRA-4364) Compaction invalidates row cache
Marcus Eriksson created CASSANDRA-4364: -- Summary: Compaction invalidates row cache Key: CASSANDRA-4364 URL: https://issues.apache.org/jira/browse/CASSANDRA-4364 Project: Cassandra Issue Type: Bug Affects Versions: 1.2 Reporter: Marcus Eriksson Priority: Minor Compactions invalidate row cache after CASSANDRA-3862 https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionIterable.java#L87 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4365) Use CF comparator to sort indexed columns in SecondaryIndexManager
[ https://issues.apache.org/jira/browse/CASSANDRA-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4365: Attachment: 4365.txt Use CF comparator to sort indexed columns in SecondaryIndexManager -- Key: CASSANDRA-4365 URL: https://issues.apache.org/jira/browse/CASSANDRA-4365 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 1.1.2 Attachments: 4365.txt SecondaryIndexManager is supposed to have it's internal map sorted according to the base CF comparator, but instead it sorts using the byte buffer natural ordering. This order is carried along by the sorted set returned by getIndexedColumns(), which in turns end up in a NamesQueryFilter when reading indexed columns, so the order should really be the CF one. I'll note that I don't think this is a bug because SSTableNamesIterator don't in fact rely on the actual ordering of the names. But it's worth fixing to avoid future problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4365) Use CF comparator to sort indexed columns in SecondaryIndexManager
Sylvain Lebresne created CASSANDRA-4365: --- Summary: Use CF comparator to sort indexed columns in SecondaryIndexManager Key: CASSANDRA-4365 URL: https://issues.apache.org/jira/browse/CASSANDRA-4365 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 1.1.2 Attachments: 4365.txt SecondaryIndexManager is supposed to have it's internal map sorted according to the base CF comparator, but instead it sorts using the byte buffer natural ordering. This order is carried along by the sorted set returned by getIndexedColumns(), which in turns end up in a NamesQueryFilter when reading indexed columns, so the order should really be the CF one. I'll note that I don't think this is a bug because SSTableNamesIterator don't in fact rely on the actual ordering of the names. But it's worth fixing to avoid future problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4047) Bulk hinting
[ https://issues.apache.org/jira/browse/CASSANDRA-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398493#comment-13398493 ] Brandon Williams commented on CASSANDRA-4047: - bq. Alternatively... we can do repairs of specific ranges now. What if we stored as our hint the range we streamed, and the node that went down, and then the live node will run a partial repair with that replica when it comes back up? This sounds like a good way to do it. One wrinkle though is communication, now that bulk loading doesn't have a MS to speak with, it only has streaming or thrift available, and shunting this into either seems awkward. Bulk hinting Key: CASSANDRA-4047 URL: https://issues.apache.org/jira/browse/CASSANDRA-4047 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.2 With the introduction of the BulkOutputFormat, there may be cases where someone would like to tolerate node failures and have the job complete, but afterwards since we streamed they have to repair or rely on read repair. We don't currently have any way of hinting streams, but a node could take a snapshot before acknowledging the stream session, then remember to send the files in the snapshot to the unavailable nodes when they come back up. This isn't quite ideal since of course the node may have compacted these files, however it's much simpler than any sort of key tracking at this scale. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4295: --- Attachment: CASSANDRA-4295.patch move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1.2 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3564) flush before shutdown so restart is faster
[ https://issues.apache.org/jira/browse/CASSANDRA-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398515#comment-13398515 ] Brandon Williams commented on CASSANDRA-3564: - The catch with flushandexit is, you have no way of knowing if it worked or not (from nodetool's perspective) since either way, you're going to get an error (EOF because the jvm shutdown, or EOF because ???) bq. kill -KILL = lose most recent writes unless durable_writes=true and batch commits are on [also current behavior] Unless I'm missing something, you can't do anything about a kill -9, you're cooked. Anyway, the code looks good to me. flush before shutdown so restart is faster -- Key: CASSANDRA-3564 URL: https://issues.apache.org/jira/browse/CASSANDRA-3564 Project: Cassandra Issue Type: New Feature Components: Packaging Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 3564.patch Cassandra handles flush in its shutdown hook for durable_writes=false CFs (otherwise we're *guaranteed* to lose data) but leaves it up to the operator otherwise. I'd rather leave it that way to offer these semantics: - cassandra stop = shutdown nicely [explicit flush, then kill -int] - kill -INT = shutdown faster but don't lose any updates [current behavior] - kill -KILL = lose most recent writes unless durable_writes=true and batch commits are on [also current behavior] But if it's not reasonable to use nodetool from the init script then I guess we can just make the shutdown hook flush everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3564) flush before shutdown so restart is faster
[ https://issues.apache.org/jira/browse/CASSANDRA-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398546#comment-13398546 ] David Alves commented on CASSANDRA-3564: thanks for the review bq. The catch with flushandexit is, you have no way of knowing if it worked or not (from nodetool's perspective) since either way, you're going to get an error (EOF because the jvm shutdown, or EOF because ???) right, I thought about that (might even deserve some special error handling) but the only alternative that I could think was to make the call async so the RPC method would return fine. But even that wouldn't provide any meaningful feedback since the user would still have no idea whether things flushed ok so I left it as is. If its alright, I'll finish up by adding the cassandra stop command to the shell script and handle the broken rpc call. flush before shutdown so restart is faster -- Key: CASSANDRA-3564 URL: https://issues.apache.org/jira/browse/CASSANDRA-3564 Project: Cassandra Issue Type: New Feature Components: Packaging Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 3564.patch Cassandra handles flush in its shutdown hook for durable_writes=false CFs (otherwise we're *guaranteed* to lose data) but leaves it up to the operator otherwise. I'd rather leave it that way to offer these semantics: - cassandra stop = shutdown nicely [explicit flush, then kill -int] - kill -INT = shutdown faster but don't lose any updates [current behavior] - kill -KILL = lose most recent writes unless durable_writes=true and batch commits are on [also current behavior] But if it's not reasonable to use nodetool from the init script then I guess we can just make the shutdown hook flush everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4054) SStableImport and SStableExport does not serialize row level deletion
[ https://issues.apache.org/jira/browse/CASSANDRA-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398548#comment-13398548 ] Yuki Morishita commented on CASSANDRA-4054: --- SSTableImport seems it does not handle SuperColumn deletion as well. (It has been commented out for long time.) How about extending writeMeta/parseCFMetadata to accept SuperColumn (or more precisely, AbstractColumnContainer) and use them when handling both row and SuperColumn? Also, it would be great if you remove whitespaces on empty line and always put braces on new line. SStableImport and SStableExport does not serialize row level deletion - Key: CASSANDRA-4054 URL: https://issues.apache.org/jira/browse/CASSANDRA-4054 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.5 Reporter: Zhu Han Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 4054.patch SSTableImport and SSTableExport does not serialize/de-serialize the row-level deletion info to/from the json file. This brings back the deleted data after restore from the json file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3564) flush before shutdown so restart is faster
[ https://issues.apache.org/jira/browse/CASSANDRA-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398553#comment-13398553 ] Brandon Williams commented on CASSANDRA-3564: - bq. But even that wouldn't provide any meaningful feedback since the user would still have no idea whether things flushed ok so I left it as is. Right, there's no perfect solution here that I can see. bq. If its alright, I'll finish up by adding the cassandra stop command to the shell script and handle the broken rpc call. Sure, but this is where is gets a little more complicated, since after receiving the error the init script needs to check that the pid is really gone, and if not get more forceful. flush before shutdown so restart is faster -- Key: CASSANDRA-3564 URL: https://issues.apache.org/jira/browse/CASSANDRA-3564 Project: Cassandra Issue Type: New Feature Components: Packaging Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 3564.patch Cassandra handles flush in its shutdown hook for durable_writes=false CFs (otherwise we're *guaranteed* to lose data) but leaves it up to the operator otherwise. I'd rather leave it that way to offer these semantics: - cassandra stop = shutdown nicely [explicit flush, then kill -int] - kill -INT = shutdown faster but don't lose any updates [current behavior] - kill -KILL = lose most recent writes unless durable_writes=true and batch commits are on [also current behavior] But if it's not reasonable to use nodetool from the init script then I guess we can just make the shutdown hook flush everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4321) stackoverflow building interval tree possible sstable corruptions
[ https://issues.apache.org/jira/browse/CASSANDRA-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398563#comment-13398563 ] Omid Aladini commented on CASSANDRA-4321: - I experienced the same as Anton's. One observation is that the out-of-order key being wrongly iterated by CompactionIterable's MergeIterator which causes the exception, happen to be the start of an interval: DEBUG 18:10:41,693 Creating IntervalNode from [... Interval(DecoratedKey(33736808147257072541807562080745136438, ... ), which leads me to suspect if it's due to the Range (vs. Bounds) used in LeveledCompactionStrategy::getScanners. Any ideas? stackoverflow building interval tree possible sstable corruptions --- Key: CASSANDRA-4321 URL: https://issues.apache.org/jira/browse/CASSANDRA-4321 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Reporter: Anton Winter Assignee: Sylvain Lebresne Fix For: 1.1.2 Attachments: 0001-Change-Range-Bounds-in-LeveledManifest.overlapping-v5.txt, 0002-Scrub-detects-and-repair-outOfOrder-rows-v5.txt, 0003-Create-standalone-scrub-v5.txt, ooyala-hastur-stacktrace.txt After upgrading to 1.1.1 (from 1.1.0) I have started experiencing StackOverflowError's resulting in compaction backlog and failure to restart. The ring currently consists of 6 DC's and 22 nodes using LCS compression. This issue was first noted on 2 nodes in one DC and then appears to have spread to various other nodes in the other DC's. When the first occurrence of this was found I restarted the instance but it failed to start so I cleared its data and treated it as a replacement node for the token it was previously responsible for. This node successfully streamed all the relevant data back but failed again a number of hours later with the same StackOverflowError and again was unable to restart. The initial stack overflow error on a running instance looks like this: ERROR [CompactionExecutor:314] 2012-06-07 09:59:43,017 AbstractCassandraDaemon.java (line 134) Exception in thread Thread[CompactionExecutor:314,1,main] java.lang.StackOverflowError at java.util.Arrays.mergeSort(Arrays.java:1157) at java.util.Arrays.sort(Arrays.java:1092) at java.util.Collections.sort(Collections.java:134) at org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:114) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:49) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) [snip - this repeats until stack overflow. Compactions stop from this point onwards] I restarted this failing instance with DEBUG logging enabled and it throws the following exception part way through startup: ERROR 11:37:51,046 Exception in thread Thread[OptionalTasks:1,5,main] java.lang.StackOverflowError at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:307) at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276) at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230) at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124) at org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:228) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:45) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) [snip - this repeats until stack overflow] at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:64) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:62)
[jira] [Commented] (CASSANDRA-3564) flush before shutdown so restart is faster
[ https://issues.apache.org/jira/browse/CASSANDRA-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398571#comment-13398571 ] David Alves commented on CASSANDRA-3564: bq. Sure, but this is where is gets a little more complicated, since after receiving the error the init script needs to check that the pid is really gone, and if not get more forceful. hum... handn't thought about that. you're right. any script/code comes to mind that has similar functionality? (for inspiration :)) flush before shutdown so restart is faster -- Key: CASSANDRA-3564 URL: https://issues.apache.org/jira/browse/CASSANDRA-3564 Project: Cassandra Issue Type: New Feature Components: Packaging Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 3564.patch Cassandra handles flush in its shutdown hook for durable_writes=false CFs (otherwise we're *guaranteed* to lose data) but leaves it up to the operator otherwise. I'd rather leave it that way to offer these semantics: - cassandra stop = shutdown nicely [explicit flush, then kill -int] - kill -INT = shutdown faster but don't lose any updates [current behavior] - kill -KILL = lose most recent writes unless durable_writes=true and batch commits are on [also current behavior] But if it's not reasonable to use nodetool from the init script then I guess we can just make the shutdown hook flush everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3564) flush before shutdown so restart is faster
[ https://issues.apache.org/jira/browse/CASSANDRA-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398578#comment-13398578 ] Brandon Williams commented on CASSANDRA-3564: - I'm pretty sure the init script is already tracking the pid in a file and probably has a function to check if it's alive, so it's just a matter of doing that and issuing an extra kill if needed. flush before shutdown so restart is faster -- Key: CASSANDRA-3564 URL: https://issues.apache.org/jira/browse/CASSANDRA-3564 Project: Cassandra Issue Type: New Feature Components: Packaging Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 3564.patch Cassandra handles flush in its shutdown hook for durable_writes=false CFs (otherwise we're *guaranteed* to lose data) but leaves it up to the operator otherwise. I'd rather leave it that way to offer these semantics: - cassandra stop = shutdown nicely [explicit flush, then kill -int] - kill -INT = shutdown faster but don't lose any updates [current behavior] - kill -KILL = lose most recent writes unless durable_writes=true and batch commits are on [also current behavior] But if it's not reasonable to use nodetool from the init script then I guess we can just make the shutdown hook flush everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4365) Use CF comparator to sort indexed columns in SecondaryIndexManager
[ https://issues.apache.org/jira/browse/CASSANDRA-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398584#comment-13398584 ] Jonathan Ellis commented on CASSANDRA-4365: --- +1 Use CF comparator to sort indexed columns in SecondaryIndexManager -- Key: CASSANDRA-4365 URL: https://issues.apache.org/jira/browse/CASSANDRA-4365 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 1.1.2 Attachments: 4365.txt SecondaryIndexManager is supposed to have it's internal map sorted according to the base CF comparator, but instead it sorts using the byte buffer natural ordering. This order is carried along by the sorted set returned by getIndexedColumns(), which in turns end up in a NamesQueryFilter when reading indexed columns, so the order should really be the CF one. I'll note that I don't think this is a bug because SSTableNamesIterator don't in fact rely on the actual ordering of the names. But it's worth fixing to avoid future problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4047) Bulk hinting
[ https://issues.apache.org/jira/browse/CASSANDRA-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398586#comment-13398586 ] Jonathan Ellis commented on CASSANDRA-4047: --- Is this where we throw up our hands and finally add multi-port ability for MessagingService? Bulk hinting Key: CASSANDRA-4047 URL: https://issues.apache.org/jira/browse/CASSANDRA-4047 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.2 With the introduction of the BulkOutputFormat, there may be cases where someone would like to tolerate node failures and have the job complete, but afterwards since we streamed they have to repair or rely on read repair. We don't currently have any way of hinting streams, but a node could take a snapshot before acknowledging the stream session, then remember to send the files in the snapshot to the unavailable nodes when they come back up. This isn't quite ideal since of course the node may have compacted these files, however it's much simpler than any sort of key tracking at this scale. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4295: -- Assignee: Sylvain Lebresne (was: Pavel Yaskevich) move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.1.2 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4295: -- Reviewer: slebresne (was: jbellis) Assignee: Pavel Yaskevich (was: Sylvain Lebresne) move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1.2 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4362) cqlsh can't display reversed type values properly
[
https://issues.apache.org/jira/browse/CASSANDRA-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398603#comment-13398603
]
paul cannon commented on CASSANDRA-4362:
As a workaround, you can tell cqlsh explicitly to treat the b column as bigint:
{noformat}
ASSUME t1(b) VALUES ARE bigint;
{noformat}
That will last until the end of the session. (You might need the patch from
CASSANDRA-4352).
cqlsh can't display reversed type values properly
-
Key: CASSANDRA-4362
URL: https://issues.apache.org/jira/browse/CASSANDRA-4362
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.1
Reporter: Ahmet AKYOL
Priority: Minor
Labels: cqlsh
Here is table and data:
CREATE TABLE t1 (
a int,
b bigint,
c varchar,
d varchar,
PRIMARY KEY (a,b,c)
) WITH CLUSTERING ORDER BY (b DESC, c DESC);
INSERT INTO db.t1 (a,b,c,d) VALUES (1,10,'u1','s1');
INSERT INTO db.t1 (a,b,c,d) VALUES (1,15,'u1','d1');
INSERT INTO db.t1 (a,b,c,d) VALUES (1,21,'u3','ghfgh f1g');
INSERT INTO db.t1 (a,b,c,d) VALUES (1,31,'u2','1gh');
INSERT INTO db.t1 (a,b,c,d) VALUES (1,41,'u3','fgh1');
And here's the query
cqlsh:db SELECT * FROM t1;
a | b| c | d
---+--++---
1 |\x00\x00\x00\x00\x00\x00\x00) | u3 | fgh1
1 | \x00\x00\x00\x00\x00\x00\x00\x1f | u2 | 1gh
1 | \x00\x00\x00\x00\x00\x00\x00\x15 | u3 | ghfgh f1g
1 | \x00\x00\x00\x00\x00\x00\x00\x0f | u1 |d1
1 | \x00\x00\x00\x00\x00\x00\x00\n | u1 |s1
As you can see, cqlsh can't display reversed type values properly ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398605#comment-13398605 ] Vijay commented on CASSANDRA-2819: -- +1 Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.1.2 Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3942) ColumnFamilyRecordReader can report progress 100%
[ https://issues.apache.org/jira/browse/CASSANDRA-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-3942: Attachment: 3942.txt Patch to clamp getProgress to 1.0 or less. ColumnFamilyRecordReader can report progress 100% --- Key: CASSANDRA-3942 URL: https://issues.apache.org/jira/browse/CASSANDRA-3942 Project: Cassandra Issue Type: Bug Affects Versions: 0.6 Reporter: T Jake Luciani Assignee: Brandon Williams Priority: Minor Fix For: 1.1.2 Attachments: 3942.txt CFRR.getProgress() can return a value 1.0 since the totalRowCount is a estimate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4332) IndexRangeSliceQuery results contain IndexColumn even though it is not included in SliceRange
[ https://issues.apache.org/jira/browse/CASSANDRA-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398612#comment-13398612 ] Jonathan Ellis commented on CASSANDRA-4332: --- Can you reproduce on a single-node cluster, or does it need multiple nodes to show problems? IndexRangeSliceQuery results contain IndexColumn even though it is not included in SliceRange - Key: CASSANDRA-4332 URL: https://issues.apache.org/jira/browse/CASSANDRA-4332 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.1 Reporter: Roland Gude Attachments: system.log, system.log, system.log This is the magical reappearance of CASSANDRA-2964 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4147) add NULL to CQL3
[
https://issues.apache.org/jira/browse/CASSANDRA-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398636#comment-13398636
]
paul cannon commented on CASSANDRA-4147:
This seems like a dupe of CASSANDRA-3783 then.
add NULL to CQL3
Key: CASSANDRA-4147
URL: https://issues.apache.org/jira/browse/CASSANDRA-4147
Project: Cassandra
Issue Type: New Feature
Reporter: T Jake Luciani
Priority: Minor
Fix For: 1.1.2
cqlsh:cfs insert into foo (key,val1,val2)values('row2',NULL,NULL);
Bad Request: unable to make long from 'NULL'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3707) Add KeyspaceChange CqlResultType
[ https://issues.apache.org/jira/browse/CASSANDRA-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398642#comment-13398642 ] paul cannon commented on CASSANDRA-3707: Yeah, but I'm not sure it's common for client libs to need that information (what keyspace was used with query Q). The programmer should generally know what keyspace is being used with a given query. Do you have a use case? Add KeyspaceChange CqlResultType Key: CASSANDRA-3707 URL: https://issues.apache.org/jira/browse/CASSANDRA-3707 Project: Cassandra Issue Type: Sub-task Components: API Reporter: Jonathan Ellis Assignee: satish babu krishnamoorthy Labels: cql Fix For: 1.1.2 High level clients want to handle failover and load balancing transparently to the application, which means not just connection pooling but moving an existing connection to another server if necessary. When this happens, the client needs to know what the active keyspace was before failover, so it can set it to the same one in the new connection. Currently some clients handle this by checking for SET KEYSPACE queries, which violates the design principle that clients shouldn't have to parse CQL. Adding a new CqlResultType (that is set in response to a SET KEYSPACE command) would make this unnecessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4119) Support multiple non-consecutive tokens per host (virtual nodes)
[ https://issues.apache.org/jira/browse/CASSANDRA-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398644#comment-13398644 ] Sam Overton commented on CASSANDRA-4119: Brandon, I can't reproduce this difference either. Is debug logging turned on? If so, try with it off. What replication strategy snitch are you using? Is the dynamic snitch on? The only piece of code on the insert path that these patches touch is calculateNaturalEndpoints, which is cached in AbstractReplicationStrategy anyway so it's not immediately clear to me what could cause such a discrepancy in performance for you. I'll do some more thorough testing and profiling tomorrow. Support multiple non-consecutive tokens per host (virtual nodes) Key: CASSANDRA-4119 URL: https://issues.apache.org/jira/browse/CASSANDRA-4119 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sam Overton Assignee: Sam Overton Labels: virtualnodes, vnodes This is the parent ticket for the virtual nodes implementation which was proposed here: http://www.mail-archive.com/dev@cassandra.apache.org/msg03837.html and discussed in the subsequent thread. The goals of this ticket are: * reduced operations complexity for scaling up/down * reduced rebuild time in event of failure * evenly distributed load impact in the event of failure * evenly distributed impact of streaming operations * more viable support for heterogeneity of hardware The intention is that this can be done in a way which is * fully backwards-compatible * optionally enabled The latter of these can be trivially achieved by setting the number of tokens per host to 1, to reproduce the existing behaviour. Implementation detail can be added and discussed in the sub-tickets, but here is an overview of the proposed changes: * TokenMetadata will allow multiple tokens per host * Hosts will be referred to by a UUID instead of token (e.g. in Gossip, when storing hints, etc.) * A bootstrapping node can get multiple tokens from initial_token (comma separated) or by random allocation * NetworkTopologyStrategy will be extended to be aware of virtual nodes so that replicas are not placed on the same host (similar to racks now) * Repairs will be staggered similar to CASSANDRA-3721 * Nodetool operations will be virtual-node aware, while maintaining backwards compatibility (ie. existing scripts won't have to change) * Upgrade will be a standard rolling upgrade, with optional rolling migration to full vnode support -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4325) CQL unable to drop columnfamily
[ https://issues.apache.org/jira/browse/CASSANDRA-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398648#comment-13398648 ] paul cannon commented on CASSANDRA-4325: Can't reproduce. Can you provide more information, like any relevant parts of the Cassandra log, and information about your ring and your system in general? CQL unable to drop columnfamily --- Key: CASSANDRA-4325 URL: https://issues.apache.org/jira/browse/CASSANDRA-4325 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Environment: Debian 6.0.5 Squeeze Reporter: Jason Walkowicz Labels: CQL cqlsh:x DROP COLUMNFAMILY userstats ; cqlsh:x select * from userstats; key | column1 | value ---+-+--- jason |fans | 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4363) Cassandra 1.1.1 throws errors when trying the new CQL 3
[
https://issues.apache.org/jira/browse/CASSANDRA-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398657#comment-13398657
]
paul cannon commented on CASSANDRA-4363:
Jonathan means, are you able to check out the Cassandra source on the
cassandra-1.1 branch, and build and run it from there, and reproduce the
problem?
If you have no idea how to do that, it might be something like the following:
{noformat}
(kill preexisting running cassandra)
git clone http://git-wip-us.apache.org/repos/asf/cassandra.git
cd cassandra
git checkout -b cassandra-1.1 -t origin/cassandra-1.1
ant clean jar
bin/cassandra -f
{noformat}
Cassandra 1.1.1 throws errors when trying the new CQL 3
---
Key: CASSANDRA-4363
URL: https://issues.apache.org/jira/browse/CASSANDRA-4363
Project: Cassandra
Issue Type: Bug
Environment: OSX 10.7.4 , java version 1.6.0_33 , Cassandra 1.1.1
Reporter: Hussein Baghdadi
I downloaded Cassandra 1.1.1 and launched cqlsh under the version 3
I tried to create a new column family:
CREATE TABLE stats (
pid blob,
period int,
targetid blob,
sum counter,
PRIMARY KEY (pid, period, targetid)
);
But I got this:
Traceback (most recent call last): File ./cqlsh, line 908, in
perform_statement self.cursor.execute(statement, decoder=decoder) File
./../lib/cql-internal-only-1.0.10.zip/cql-1.0.10/cql/cursor.py, line 117,
in execute response = self.handle_cql_execution_errors(doquery, prepared_q,
compress) File
./../lib/cql-internal-only-1.0.10.zip/cql-1.0.10/cql/cursor.py, line 132,
in handle_cql_execution_errors return executor(*args, **kwargs) File
./../lib/cql-internal-only-1.0.10.zip/cql-1.0.10/cql/cassandra/Cassandra.py,
line 1583, in execute_cql_query self.send_execute_cql_query(query,
compression) File
./../lib/cql-internal-only-1.0.10.zip/cql-1.0.10/cql/cassandra/Cassandra.py,
line 1593, in send_execute_cql_query self.oprot.trans.flush() File
./../lib/thrift-python-internal-only-0.7.0.zip/thrift/transport/TTransport.py,
line 293, in flush self._trans.write(buf) File
./../lib/thrift-python-internal-only-0.7.0.zip/thrift/transport/TSocket.py,
line 117, in write plus = self.handle.send(buff) error: [Errno 32] Broken pipe
And on the server console:
Error occurred during processing of message.
java.lang.IllegalArgumentException at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:51)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:60)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:140)
at org.apache.cassandra.config.CFMetaData.validate(CFMetaData.java:929) at
org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:131)
at
org.apache.cassandra.cql3.statements.CreateColumnFamilyStatement.announceMigration(CreateColumnFamilyStatement.java:83)
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:99)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1237)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) at
org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
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:680)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4350) cql cassandra version reporting is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon reassigned CASSANDRA-4350:
--
Assignee: paul cannon
cql cassandra version reporting is incorrect
Key: CASSANDRA-4350
URL: https://issues.apache.org/jira/browse/CASSANDRA-4350
Project: Cassandra
Issue Type: Bug
Reporter: Jeremy Hanna
Assignee: paul cannon
Priority: Minor
Labels: cql, cqlsh
It looks like either the docs are wrong or the functionality is wrong. The
docs for show version say:
{quote}
Shows the version and build of the connected Cassandra instance, well as the
versions of the CQL spec and the Thrift protocol that the connected Cassandra
instance understands.
{quote}
On a cassandra node in the ring, I do nodetool -h localhost version and it
outputs the correct version (1.0.8). From a remote node with 1.0.9
installed, I run nodetool -h same_node_in_ring version. It outputs the
correct version. However when I start cqlsh, it shows the remote node's
version (1.0.9). Also when I use the 'show version;' command in cqlsh, it
also prints out 1.0.9.
So either the docs are incorrect and it just outputs the version of the local
build or there's a bug in show version and the startup output and it should
really show the version of the connected node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: split up rpc timeout by operation type patch by Melvin Wang and jbellis; reviewed by vijay for CASSANDRA-2819
Updated Branches: refs/heads/trunk ced78f3c4 - e6610e469 split up rpc timeout by operation type patch by Melvin Wang and jbellis; reviewed by vijay for CASSANDRA-2819 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e6610e46 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e6610e46 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e6610e46 Branch: refs/heads/trunk Commit: e6610e4692800485501e316df3dab53a6e9e34b2 Parents: ced78f3 Author: Jonathan Ellis jbel...@apache.org Authored: Wed May 16 14:49:56 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Jun 21 13:19:02 2012 -0500 -- CHANGES.txt|1 + NEWS.txt |5 + conf/cassandra.yaml| 13 +++- src/java/org/apache/cassandra/config/Config.java | 10 ++- .../cassandra/config/DatabaseDescriptor.java | 70 +++ .../org/apache/cassandra/db/RangeSliceCommand.java | 10 ++- src/java/org/apache/cassandra/db/ReadCommand.java |6 ++ .../org/apache/cassandra/dht/BootStrapper.java |2 +- .../apache/cassandra/net/MessageDeliveryTask.java |2 +- src/java/org/apache/cassandra/net/MessageIn.java |6 ++ src/java/org/apache/cassandra/net/MessageOut.java |6 ++ .../org/apache/cassandra/net/MessagingService.java | 17 +--- .../cassandra/net/OutboundTcpConnection.java |4 +- .../service/AbstractWriteResponseHandler.java |3 +- .../org/apache/cassandra/service/IReadCommand.java |1 + .../org/apache/cassandra/service/ReadCallback.java |2 +- .../apache/cassandra/service/RepairCallback.java |2 +- .../org/apache/cassandra/service/StorageProxy.java | 29 --- .../cassandra/service/StorageProxyMBean.java |8 ++ .../cassandra/service/TruncateResponseHandler.java |2 +- .../apache/cassandra/thrift/CassandraServer.java | 10 +- 21 files changed, 167 insertions(+), 42 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e6610e46/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 8da61ba..344c87b 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.2-dev + * split up rpc timeout by operation type (CASSANDRA-2819) * rewrite key cache save/load to use only sequential i/o (CASSANDRA-3762) * update MS protocol with a version handshake + broadcast address id (CASSANDRA-4311) http://git-wip-us.apache.org/repos/asf/cassandra/blob/e6610e46/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 6cad6c2..23814b1 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -36,6 +36,11 @@ Upgrading - Global option hinted_handoff_throttle_delay_in_ms has been removed. hinted_handoff_throttle_in_kb has been added instead. +Features + +- rpc_timeout has been split up to allow finer-grained control + on timeouts for different operation types + 1.1.1 = http://git-wip-us.apache.org/repos/asf/cassandra/blob/e6610e46/conf/cassandra.yaml -- diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index cddd491..a584448 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -400,7 +400,18 @@ compaction_preheat_key_cache: true # When unset, the default is 400 Mbps or 50 MB/s. # stream_throughput_outbound_megabits_per_sec: 400 -# Time to wait for a reply from other nodes before failing the command +# How long the coordinator should wait for read operations to complete +read_rpc_timeout_in_ms: 1 +# How long the coordinator should wait for seq or index scans to complete +range_rpc_timeout_in_ms: 1 +# How long the coordinator should wait for writes to complete +write_rpc_timeout_in_ms: 1 +# How long the coordinator should wait for truncates to complete +# (This can be much longer, because we need to flush all CFs +# to make sure we can clear out anythink in the commitlog that could +# cause truncated data to reappear.) +truncate_timeout_in_ms: 30 +# The default timeout for other, miscellaneous operations rpc_timeout_in_ms: 1 # Enable socket timeout for streaming operation. http://git-wip-us.apache.org/repos/asf/cassandra/blob/e6610e46/src/java/org/apache/cassandra/config/Config.java -- diff --git a/src/java/org/apache/cassandra/config/Config.java b/src/java/org/apache/cassandra/config/Config.java index e1c9a42..1cda551 100644 --- a/src/java/org/apache/cassandra/config/Config.java +++ b/src/java/org/apache/cassandra/config/Config.java @@ -45,7 +45,15 @@ public
[jira] [Resolved] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2819. --- Resolution: Fixed Fix Version/s: (was: 1.1.2) 1.2 Committed to trunk. I'm okay with backporting to 1.1 should someone step up to do that; my quick look is that it should be straightforward but not automatic (runs into things like the underscore removal). Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.2 Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398692#comment-13398692 ] Jonathan Ellis edited comment on CASSANDRA-2819 at 6/21/12 6:20 PM: Committed to trunk. I'm okay with backporting to 1.1 should someone step up to do that for 1.1.2; my quick look is that it should be straightforward but not automatic (runs into things like the underscore removal). was (Author: jbellis): Committed to trunk. I'm okay with backporting to 1.1 should someone step up to do that; my quick look is that it should be straightforward but not automatic (runs into things like the underscore removal). Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.2 Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4364) Compaction invalidates row cache
[ https://issues.apache.org/jira/browse/CASSANDRA-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398705#comment-13398705 ] Jonathan Ellis commented on CASSANDRA-4364: --- What do you sugggest instead? Compaction invalidates row cache Key: CASSANDRA-4364 URL: https://issues.apache.org/jira/browse/CASSANDRA-4364 Project: Cassandra Issue Type: Bug Affects Versions: 1.2 Reporter: Marcus Eriksson Priority: Minor Compactions invalidate row cache after CASSANDRA-3862 https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionIterable.java#L87 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4282) Improve startup time by making row cache population multi threaded
[
https://issues.apache.org/jira/browse/CASSANDRA-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398710#comment-13398710
]
Jonathan Ellis commented on CASSANDRA-4282:
---
Sorry for the delay reviewing. I'm unable to apply to current trunk or trunk
as of May 25... could you rebase?
Improve startup time by making row cache population multi threaded
--
Key: CASSANDRA-4282
URL: https://issues.apache.org/jira/browse/CASSANDRA-4282
Project: Cassandra
Issue Type: Improvement
Reporter: Marcus Eriksson
Priority: Minor
Fix For: 1.2
Attachments:
0001-improve-startup-time-by-multi-threading-row-cache-re.patch
Attached patch multi threads the row cache population
my small tests show improvements atleast;
{code}
- 4 cores
- 11G stress-generated data
- page cache dropped between runs
single platter spinning disk:
single threaded:
INFO 10:18:21,365 completed loading (245562 ms; 311381 keys) row cache for
Keyspace1.Standard1
INFO 10:32:43,738 completed loading (255106 ms; 311381 keys) row cache for
Keyspace1.Standard1
multi threaded:
INFO 10:22:47,567 completed loading (213905 ms; 311381 keys) row cache for
Keyspace1.Standard1
INFO 10:27:26,873 completed loading (214514 ms; 311381 keys) row cache for
Keyspace1.Standard1
ssd;
single threaded:
INFO 10:40:49,079 completed loading (103883 ms; 311381 keys) row cache for
Keyspace1.Standard1
INFO 10:43:45,799 completed loading (106913 ms; 311381 keys) row cache for
Keyspace1.Standard1
multi threaded:
INFO 10:38:20,798 completed loading (57617 ms; 311381 keys) row cache for
Keyspace1.Standard1
INFO 10:47:20,339 completed loading (56682 ms; 311381 keys) row cache for
Keyspace1.Standard1
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: add short-circuit abort check in searchInternal patch by Daniel Doubleday; reviewed by jbellis for CASSANDRA-3708
Updated Branches:
refs/heads/trunk e6610e469 - 84bfdf27d
add short-circuit abort check in searchInternal
patch by Daniel Doubleday; reviewed by jbellis for CASSANDRA-3708
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/84bfdf27
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/84bfdf27
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/84bfdf27
Branch: refs/heads/trunk
Commit: 84bfdf27dfbd8aa3c030fd77b188c245db9bf705
Parents: e6610e4
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Jun 21 13:36:29 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Jun 21 13:36:29 2012 -0500
--
.../org/apache/cassandra/utils/IntervalTree.java |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/84bfdf27/src/java/org/apache/cassandra/utils/IntervalTree.java
--
diff --git a/src/java/org/apache/cassandra/utils/IntervalTree.java
b/src/java/org/apache/cassandra/utils/IntervalTree.java
index ec8e166..ba9e438 100644
--- a/src/java/org/apache/cassandra/utils/IntervalTree.java
+++ b/src/java/org/apache/cassandra/utils/IntervalTree.java
@@ -290,6 +290,9 @@ public class IntervalTreeC, D, I extends IntervalC, D
implements IterableI
void searchInternal(IntervalC, D searchInterval, ListD results)
{
+if (comparePoints(searchInterval.max, low) 0 ||
comparePoints(searchInterval.min, high) 0)
+return;
+
if (contains(searchInterval, center))
{
// Adds every interval contained in this node to the result
set then search left and right for further
[jira] [Commented] (CASSANDRA-3708) Support composite prefix tombstones
[ https://issues.apache.org/jira/browse/CASSANDRA-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398722#comment-13398722 ] Jonathan Ellis commented on CASSANDRA-3708: --- lgtm, committed Support composite prefix tombstones - Key: CASSANDRA-3708 URL: https://issues.apache.org/jira/browse/CASSANDRA-3708 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4119) Support multiple non-consecutive tokens per host (virtual nodes)
[ https://issues.apache.org/jira/browse/CASSANDRA-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398732#comment-13398732 ] Brandon Williams commented on CASSANDRA-4119: - It's been some time since I last tested this, so I decided to give it another go. After updating the branch to 7e9ecd9783fbefaea13fe1b1ceb3bac46aa57291 I'm unable to reproduce, so perhaps it was some condition in trunk exacerbating the problem that has been fixed in the past ~20 days. Support multiple non-consecutive tokens per host (virtual nodes) Key: CASSANDRA-4119 URL: https://issues.apache.org/jira/browse/CASSANDRA-4119 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sam Overton Assignee: Sam Overton Labels: virtualnodes, vnodes This is the parent ticket for the virtual nodes implementation which was proposed here: http://www.mail-archive.com/dev@cassandra.apache.org/msg03837.html and discussed in the subsequent thread. The goals of this ticket are: * reduced operations complexity for scaling up/down * reduced rebuild time in event of failure * evenly distributed load impact in the event of failure * evenly distributed impact of streaming operations * more viable support for heterogeneity of hardware The intention is that this can be done in a way which is * fully backwards-compatible * optionally enabled The latter of these can be trivially achieved by setting the number of tokens per host to 1, to reproduce the existing behaviour. Implementation detail can be added and discussed in the sub-tickets, but here is an overview of the proposed changes: * TokenMetadata will allow multiple tokens per host * Hosts will be referred to by a UUID instead of token (e.g. in Gossip, when storing hints, etc.) * A bootstrapping node can get multiple tokens from initial_token (comma separated) or by random allocation * NetworkTopologyStrategy will be extended to be aware of virtual nodes so that replicas are not placed on the same host (similar to racks now) * Repairs will be staggered similar to CASSANDRA-3721 * Nodetool operations will be virtual-node aware, while maintaining backwards compatibility (ie. existing scripts won't have to change) * Upgrade will be a standard rolling upgrade, with optional rolling migration to full vnode support -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: add UseCondCardMark to default GC options
Updated Branches: refs/heads/trunk 84bfdf27d - 544f1a8ec add UseCondCardMark to default GC options Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/544f1a8e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/544f1a8e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/544f1a8e Branch: refs/heads/trunk Commit: 544f1a8ec0506d9389c48ec2ed76876142b8bfd5 Parents: 84bfdf2 Author: Jonathan Ellis jbel...@apache.org Authored: Thu Jun 21 13:46:43 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Jun 21 13:46:43 2012 -0500 -- conf/cassandra-env.sh |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/544f1a8e/conf/cassandra-env.sh -- diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh index a3ca022..4b410b5 100644 --- a/conf/cassandra-env.sh +++ b/conf/cassandra-env.sh @@ -169,6 +169,7 @@ JVM_OPTS=$JVM_OPTS -XX:SurvivorRatio=8 JVM_OPTS=$JVM_OPTS -XX:MaxTenuringThreshold=1 JVM_OPTS=$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75 JVM_OPTS=$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly +JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark # GC logging options -- uncomment to enable # JVM_OPTS=$JVM_OPTS -XX:+PrintGCDetails
[jira] [Commented] (CASSANDRA-3942) ColumnFamilyRecordReader can report progress 100%
[ https://issues.apache.org/jira/browse/CASSANDRA-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398749#comment-13398749 ] Jonathan Ellis commented on CASSANDRA-3942: --- +1 ColumnFamilyRecordReader can report progress 100% --- Key: CASSANDRA-3942 URL: https://issues.apache.org/jira/browse/CASSANDRA-3942 Project: Cassandra Issue Type: Bug Affects Versions: 0.6 Reporter: T Jake Luciani Assignee: Brandon Williams Priority: Minor Fix For: 1.1.2 Attachments: 3942.txt CFRR.getProgress() can return a value 1.0 since the totalRowCount is a estimate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4147) add NULL to CQL3
[
https://issues.apache.org/jira/browse/CASSANDRA-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-4147.
---
Resolution: Duplicate
Fix Version/s: (was: 1.1.2)
agreed.
add NULL to CQL3
Key: CASSANDRA-4147
URL: https://issues.apache.org/jira/browse/CASSANDRA-4147
Project: Cassandra
Issue Type: New Feature
Reporter: T Jake Luciani
Priority: Minor
cqlsh:cfs insert into foo (key,val1,val2)values('row2',NULL,NULL);
Bad Request: unable to make long from 'NULL'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Revert add UseCondCardMark to default GC options (not supported in 1.6?)
Updated Branches: refs/heads/trunk 544f1a8ec - 7c306cbda Revert add UseCondCardMark to default GC options (not supported in 1.6?) This reverts commit 544f1a8ec0506d9389c48ec2ed76876142b8bfd5. Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7c306cbd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7c306cbd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7c306cbd Branch: refs/heads/trunk Commit: 7c306cbdae24ad2b0aff6481d1aeaa27c97c913c Parents: 544f1a8 Author: Jonathan Ellis jbel...@apache.org Authored: Thu Jun 21 14:02:47 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Jun 21 14:02:47 2012 -0500 -- conf/cassandra-env.sh |1 - 1 files changed, 0 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7c306cbd/conf/cassandra-env.sh -- diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh index 4b410b5..a3ca022 100644 --- a/conf/cassandra-env.sh +++ b/conf/cassandra-env.sh @@ -169,7 +169,6 @@ JVM_OPTS=$JVM_OPTS -XX:SurvivorRatio=8 JVM_OPTS=$JVM_OPTS -XX:MaxTenuringThreshold=1 JVM_OPTS=$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75 JVM_OPTS=$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly -JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark # GC logging options -- uncomment to enable # JVM_OPTS=$JVM_OPTS -XX:+PrintGCDetails
[jira] [Commented] (CASSANDRA-3707) Add KeyspaceChange CqlResultType
[ https://issues.apache.org/jira/browse/CASSANDRA-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398754#comment-13398754 ] Jonathan Ellis commented on CASSANDRA-3707: --- Quoting Rick from CASSANDRA-2478: bq. Much of the pressure in the corporate world I live in is from teams that are trying to use JDBC driver for C* in the same fashion and with the same BI, ETL and statistics tools (Talend, Informatica, Datastage, SPSS, SAS) as they do for relational solutions. Many of these tools are quite comprehensive in the information they can display and use, so they are heavy users of the metadata features of the driver. Returning no data for some functions often causes the tooling to just give up, not to use what they have. However, given that we've added this functionality to the 2478 driver, do we need to mangle Thrift again to add it there too? (Since clients will need to be updated to use the new information either way...) Add KeyspaceChange CqlResultType Key: CASSANDRA-3707 URL: https://issues.apache.org/jira/browse/CASSANDRA-3707 Project: Cassandra Issue Type: Sub-task Components: API Reporter: Jonathan Ellis Assignee: satish babu krishnamoorthy Labels: cql Fix For: 1.1.2 High level clients want to handle failover and load balancing transparently to the application, which means not just connection pooling but moving an existing connection to another server if necessary. When this happens, the client needs to know what the active keyspace was before failover, so it can set it to the same one in the new connection. Currently some clients handle this by checking for SET KEYSPACE queries, which violates the design principle that clients shouldn't have to parse CQL. Adding a new CqlResultType (that is set in response to a SET KEYSPACE command) would make this unnecessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4366) add UseCondCardMark XX jvm settings on jdk 1.7
Dave Brosius created CASSANDRA-4366: --- Summary: add UseCondCardMark XX jvm settings on jdk 1.7 Key: CASSANDRA-4366 URL: https://issues.apache.org/jira/browse/CASSANDRA-4366 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Fix For: 1.2 found by jbellis adding jvm extension setting UseCondCardMark as defined here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029167 for better lock handling especially on hotspot with multicore processors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4366) add UseCondCardMark XX jvm settings on jdk 1.7
[ https://issues.apache.org/jira/browse/CASSANDRA-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-4366: Attachment: 4366.txt add UseCondCardMark XX jvm settings on jdk 1.7 -- Key: CASSANDRA-4366 URL: https://issues.apache.org/jira/browse/CASSANDRA-4366 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Fix For: 1.2 Attachments: 4366.txt found by jbellis adding jvm extension setting UseCondCardMark as defined here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029167 for better lock handling especially on hotspot with multicore processors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4366) add UseCondCardMark XX jvm settings on jdk 1.7
[ https://issues.apache.org/jira/browse/CASSANDRA-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398766#comment-13398766 ] Jonathan Ellis commented on CASSANDRA-4366: --- +1 add UseCondCardMark XX jvm settings on jdk 1.7 -- Key: CASSANDRA-4366 URL: https://issues.apache.org/jira/browse/CASSANDRA-4366 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Fix For: 1.2 Attachments: 4366.txt found by jbellis adding jvm extension setting UseCondCardMark as defined here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029167 for better lock handling especially on hotspot with multicore processors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: fix typo (spilleng)
Updated Branches: refs/heads/trunk 7c306cbda - 67e4fdb43 fix typo (spilleng) Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/67e4fdb4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/67e4fdb4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/67e4fdb4 Branch: refs/heads/trunk Commit: 67e4fdb439dfdbf3ecca7c2ef4bd35fad3714b9e Parents: 7c306cb Author: Dave Brosius dbros...@apache.org Authored: Thu Jun 21 15:21:23 2012 -0400 Committer: Dave Brosius dbros...@apache.org Committed: Thu Jun 21 15:21:23 2012 -0400 -- conf/cassandra.yaml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/67e4fdb4/conf/cassandra.yaml -- diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index a584448..6d499c7 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -410,7 +410,7 @@ write_rpc_timeout_in_ms: 1 # (This can be much longer, because we need to flush all CFs # to make sure we can clear out anythink in the commitlog that could # cause truncated data to reappear.) -truncate_timeout_in_ms: 30 +truncate_rpc_timeout_in_ms: 30 # The default timeout for other, miscellaneous operations rpc_timeout_in_ms: 1
[jira] [Commented] (CASSANDRA-4325) CQL unable to drop columnfamily
[ https://issues.apache.org/jira/browse/CASSANDRA-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398774#comment-13398774 ] Jason Walkowicz commented on CASSANDRA-4325: I rebooted the server and it works now. CQL unable to drop columnfamily --- Key: CASSANDRA-4325 URL: https://issues.apache.org/jira/browse/CASSANDRA-4325 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Environment: Debian 6.0.5 Squeeze Reporter: Jason Walkowicz Labels: CQL cqlsh:x DROP COLUMNFAMILY userstats ; cqlsh:x select * from userstats; key | column1 | value ---+-+--- jason |fans | 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4325) CQL unable to drop columnfamily
[ https://issues.apache.org/jira/browse/CASSANDRA-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398788#comment-13398788 ] paul cannon commented on CASSANDRA-4325: Would you rather assume there was something busted in your system then, and close this ticket -- or leave it open and still provide the additional info? CQL unable to drop columnfamily --- Key: CASSANDRA-4325 URL: https://issues.apache.org/jira/browse/CASSANDRA-4325 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Environment: Debian 6.0.5 Squeeze Reporter: Jason Walkowicz Labels: CQL cqlsh:x DROP COLUMNFAMILY userstats ; cqlsh:x select * from userstats; key | column1 | value ---+-+--- jason |fans | 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[1/3] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/cassandra-1.1 65b09c8c9 - 8128119a0 refs/heads/trunk 67e4fdb43 - 1ecd9b7e9 Merge branch 'cassandra-1.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1ecd9b7e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1ecd9b7e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1ecd9b7e Branch: refs/heads/trunk Commit: 1ecd9b7e9dd472705c5eeec7dfadccc87f879a16 Parents: 67e4fdb 8128119 Author: Brandon Williams brandonwilli...@apache.org Authored: Thu Jun 21 14:43:10 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Thu Jun 21 14:43:10 2012 -0500 -- .../cassandra/hadoop/ColumnFamilyRecordReader.java |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/1ecd9b7e/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java --
[2/3] git commit: Bound CFRR progress to 100%. Patch by brandonwilliams reviewed by jbellis for CASSANDRA-3942
Bound CFRR progress to 100%.
Patch by brandonwilliams reviewed by jbellis for CASSANDRA-3942
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8128119a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8128119a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8128119a
Branch: refs/heads/trunk
Commit: 8128119a04f04a89efaf3808d5ebcc4a06cc12a7
Parents: 65b09c8
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Jun 21 14:41:25 2012 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Jun 21 14:41:25 2012 -0500
--
.../cassandra/hadoop/ColumnFamilyRecordReader.java |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8128119a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
index f4a2a7b..498b00c 100644
--- a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
+++ b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
@@ -108,7 +108,8 @@ public class ColumnFamilyRecordReader extends
RecordReaderByteBuffer, SortedMap
{
// TODO this is totally broken for wide rows
// the progress is likely to be reported slightly off the actual but
close enough
-return ((float)iter.rowsRead()) / totalRowCount;
+float progress = ((float) iter.rowsRead() / totalRowCount);
+return progress 1.0F ? 1.0F : progress;
}
static boolean isEmptyPredicate(SlicePredicate predicate)
[3/3] git commit: Bound CFRR progress to 100%. Patch by brandonwilliams reviewed by jbellis for CASSANDRA-3942
Bound CFRR progress to 100%.
Patch by brandonwilliams reviewed by jbellis for CASSANDRA-3942
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8128119a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8128119a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8128119a
Branch: refs/heads/cassandra-1.1
Commit: 8128119a04f04a89efaf3808d5ebcc4a06cc12a7
Parents: 65b09c8
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Jun 21 14:41:25 2012 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Jun 21 14:41:25 2012 -0500
--
.../cassandra/hadoop/ColumnFamilyRecordReader.java |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8128119a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
index f4a2a7b..498b00c 100644
--- a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
+++ b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
@@ -108,7 +108,8 @@ public class ColumnFamilyRecordReader extends
RecordReaderByteBuffer, SortedMap
{
// TODO this is totally broken for wide rows
// the progress is likely to be reported slightly off the actual but
close enough
-return ((float)iter.rowsRead()) / totalRowCount;
+float progress = ((float) iter.rowsRead() / totalRowCount);
+return progress 1.0F ? 1.0F : progress;
}
static boolean isEmptyPredicate(SlicePredicate predicate)
git commit: add UseCondCardMark XX jvm settings on jdk 1.7 patch by jbellis reviewed by dbrosius for CASSANDRA-4366
Updated Branches: refs/heads/trunk 1ecd9b7e9 - ecda83471 add UseCondCardMark XX jvm settings on jdk 1.7 patch by jbellis reviewed by dbrosius for CASSANDRA-4366 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ecda8347 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ecda8347 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ecda8347 Branch: refs/heads/trunk Commit: ecda83471c94d7bb1afc7e3ae7e45f760b8ab572 Parents: 1ecd9b7 Author: Dave Brosius dbros...@apache.org Authored: Thu Jun 21 16:01:59 2012 -0400 Committer: Dave Brosius dbros...@apache.org Committed: Thu Jun 21 16:03:40 2012 -0400 -- CHANGES.txt |2 +- conf/cassandra-env.sh |4 2 files changed, 5 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ecda8347/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 344c87b..0e717d0 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,11 +1,11 @@ 1.2-dev + * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366) * split up rpc timeout by operation type (CASSANDRA-2819) * rewrite key cache save/load to use only sequential i/o (CASSANDRA-3762) * update MS protocol with a version handshake + broadcast address id (CASSANDRA-4311) * multithreaded hint replay (CASSANDRA-4189) * add inter-node message compression (CASSANDRA-3127) - * enforce 1m min keycache for auto (CASSANDRA-4306) * remove COPP (CASSANDRA-2479) * Track tombstone expiration and compact when tombstone content is higher than a configurable threshold, default 20% (CASSANDRA-3442) http://git-wip-us.apache.org/repos/asf/cassandra/blob/ecda8347/conf/cassandra-env.sh -- diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh index a3ca022..6d71171 100644 --- a/conf/cassandra-env.sh +++ b/conf/cassandra-env.sh @@ -169,6 +169,10 @@ JVM_OPTS=$JVM_OPTS -XX:SurvivorRatio=8 JVM_OPTS=$JVM_OPTS -XX:MaxTenuringThreshold=1 JVM_OPTS=$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75 JVM_OPTS=$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly +if [ $java_version = 1.7 ] +then +JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark +fi # GC logging options -- uncomment to enable # JVM_OPTS=$JVM_OPTS -XX:+PrintGCDetails
[jira] [Assigned] (CASSANDRA-4366) add UseCondCardMark XX jvm settings on jdk 1.7
[ https://issues.apache.org/jira/browse/CASSANDRA-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius reassigned CASSANDRA-4366: --- Assignee: Jonathan Ellis add UseCondCardMark XX jvm settings on jdk 1.7 -- Key: CASSANDRA-4366 URL: https://issues.apache.org/jira/browse/CASSANDRA-4366 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 1.2 Reporter: Dave Brosius Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.2 Attachments: 4366.txt found by jbellis adding jvm extension setting UseCondCardMark as defined here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029167 for better lock handling especially on hotspot with multicore processors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4366) add UseCondCardMark XX jvm settings on jdk 1.7
[ https://issues.apache.org/jira/browse/CASSANDRA-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-4366: Reviewer: dbros...@apache.org add UseCondCardMark XX jvm settings on jdk 1.7 -- Key: CASSANDRA-4366 URL: https://issues.apache.org/jira/browse/CASSANDRA-4366 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 1.2 Reporter: Dave Brosius Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.2 Attachments: 4366.txt found by jbellis adding jvm extension setting UseCondCardMark as defined here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029167 for better lock handling especially on hotspot with multicore processors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4366) add UseCondCardMark XX jvm settings on jdk 1.7
[ https://issues.apache.org/jira/browse/CASSANDRA-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398811#comment-13398811 ] Dave Brosius commented on CASSANDRA-4366: - committed to trunk as commit ecda83471c94d7bb1afc7e3ae7e45f760b8ab572 add UseCondCardMark XX jvm settings on jdk 1.7 -- Key: CASSANDRA-4366 URL: https://issues.apache.org/jira/browse/CASSANDRA-4366 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 1.2 Reporter: Dave Brosius Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.2 Attachments: 4366.txt found by jbellis adding jvm extension setting UseCondCardMark as defined here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029167 for better lock handling especially on hotspot with multicore processors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4366) add UseCondCardMark XX jvm settings on jdk 1.7
[ https://issues.apache.org/jira/browse/CASSANDRA-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius resolved CASSANDRA-4366. - Resolution: Fixed add UseCondCardMark XX jvm settings on jdk 1.7 -- Key: CASSANDRA-4366 URL: https://issues.apache.org/jira/browse/CASSANDRA-4366 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 1.2 Reporter: Dave Brosius Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.2 Attachments: 4366.txt found by jbellis adding jvm extension setting UseCondCardMark as defined here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029167 for better lock handling especially on hotspot with multicore processors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-2819) Split rpc timeout for read and write ops
[
https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reopened CASSANDRA-2819:
-
Assignee: Jonathan Ellis (was: Melvin Wang)
The target can be null when the host is killed before it fires:
{noformat}
ERROR [EXPIRING-MAP-REAPER:1] 2012-06-21 15:55:27,708
AbstractCassandraDaemon.java (line 133) Exception in thread
Thread[EXPIRING-MAP-REAPER:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:326)
at
org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:322)
at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:99)
at
org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:75)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
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)
{noformat}
Split rpc timeout for read and write ops
Key: CASSANDRA-2819
URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 1.2
Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt,
2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
Given the vastly different latency characteristics of reads and writes, it
makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4366) add UseCondCardMark XX jvm settings on jdk 1.7
[ https://issues.apache.org/jira/browse/CASSANDRA-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4366: -- Reviewer: jbellis (was: dbros...@apache.org) Assignee: Dave Brosius (was: Jonathan Ellis) add UseCondCardMark XX jvm settings on jdk 1.7 -- Key: CASSANDRA-4366 URL: https://issues.apache.org/jira/browse/CASSANDRA-4366 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 1.2 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 1.2 Attachments: 4366.txt found by jbellis adding jvm extension setting UseCondCardMark as defined here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029167 for better lock handling especially on hotspot with multicore processors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
[
https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399041#comment-13399041
]
Vijay commented on CASSANDRA-2819:
--
{quote}
The target can be null when the host is killed before it fires
{quote}
I think the NPE is because CallbackInfo.sentMessage is null right?
i think it is better to move store the timeout value in the CallbackInfo...
Split rpc timeout for read and write ops
Key: CASSANDRA-2819
URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 1.2
Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt,
2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
Given the vastly different latency characteristics of reads and writes, it
makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399042#comment-13399042 ] Jonathan Ellis commented on CASSANDRA-2819: --- Right. This is broken, reverted. Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Jonathan Ellis Fix For: 1.2 Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399052#comment-13399052 ] Jonathan Ellis commented on CASSANDRA-2819: --- We already have the timeout info in the EM entry, probably simplest to just pass that to the reporter method instead of storing it redundantly in the callback as well. Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Jonathan Ellis Fix For: 1.2 Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-2819: - Attachment: 0001-additional-fix-for-2819.patch Fix for NPE. Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Jonathan Ellis Fix For: 1.2 Attachments: 0001-additional-fix-for-2819.patch, 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3564) flush before shutdown so restart is faster
[ https://issues.apache.org/jira/browse/CASSANDRA-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399090#comment-13399090 ] David Alves commented on CASSANDRA-3564: bq. Sure, but this is where is gets a little more complicated, since after receiving the error the init script needs to check that the pid is really gone, and if not get more forceful. was about to implement this when a problem came to mind. There's no time limit on how long a flush will take and shutdown hooks can take as long as needed to finish up so we have no idea when to get more forceful. There's two ways we could deal with this IMO: - we poll-check on the pid, nodetool side, and give it an umbrella grace period to do everything, after that we SIGKILL it - we simply inform that it might take a while. flush before shutdown so restart is faster -- Key: CASSANDRA-3564 URL: https://issues.apache.org/jira/browse/CASSANDRA-3564 Project: Cassandra Issue Type: New Feature Components: Packaging Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 3564.patch Cassandra handles flush in its shutdown hook for durable_writes=false CFs (otherwise we're *guaranteed* to lose data) but leaves it up to the operator otherwise. I'd rather leave it that way to offer these semantics: - cassandra stop = shutdown nicely [explicit flush, then kill -int] - kill -INT = shutdown faster but don't lose any updates [current behavior] - kill -KILL = lose most recent writes unless durable_writes=true and batch commits are on [also current behavior] But if it's not reasonable to use nodetool from the init script then I guess we can just make the shutdown hook flush everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3564) flush before shutdown so restart is faster
[ https://issues.apache.org/jira/browse/CASSANDRA-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399091#comment-13399091 ] Brandon Williams commented on CASSANDRA-3564: - bq. There's no time limit on how long a flush will take and shutdown hooks can take as long as needed to finish up so we have no idea when to get more forceful. Nodetool is going to block until it's finished, at which point if the pid still exists (I guess if jmx timed out or something) we just SIGKILL it. flush before shutdown so restart is faster -- Key: CASSANDRA-3564 URL: https://issues.apache.org/jira/browse/CASSANDRA-3564 Project: Cassandra Issue Type: New Feature Components: Packaging Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 3564.patch Cassandra handles flush in its shutdown hook for durable_writes=false CFs (otherwise we're *guaranteed* to lose data) but leaves it up to the operator otherwise. I'd rather leave it that way to offer these semantics: - cassandra stop = shutdown nicely [explicit flush, then kill -int] - kill -INT = shutdown faster but don't lose any updates [current behavior] - kill -KILL = lose most recent writes unless durable_writes=true and batch commits are on [also current behavior] But if it's not reasonable to use nodetool from the init script then I guess we can just make the shutdown hook flush everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1337) parallelize fetching rows for low-cardinality indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399093#comment-13399093 ] David Alves commented on CASSANDRA-1337: Thanks for the review Vijay. I have nothing to add... parallelize fetching rows for low-cardinality indexes - Key: CASSANDRA-1337 URL: https://issues.apache.org/jira/browse/CASSANDRA-1337 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2 Attachments: 0001-CASSANDRA-1337-scan-concurrently-depending-on-num-rows.txt, CASSANDRA-1337.patch Original Estimate: 8h Remaining Estimate: 8h currently, we read the indexed rows from the first node (in partitioner order); if that does not have enough matching rows, we read the rows from the next, and so forth. we should use the statistics fom CASSANDRA-1155 to query multiple nodes in parallel, such that we have a high chance of getting enough rows w/o having to do another round of queries (but, if our estimate is incorrect, we do need to loop and do more rounds until we have enough data or we have fetched from each node). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: parallelize fetching rows for low-cardinality indexes patch by David Alves; reviewed by Vijay for CASSANDRA-1337
Updated Branches:
refs/heads/trunk ecda83471 - 9cf915fd4
parallelize fetching rows for low-cardinality indexes
patch by David Alves; reviewed by Vijay for CASSANDRA-1337
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9cf915fd
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9cf915fd
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9cf915fd
Branch: refs/heads/trunk
Commit: 9cf915fd464b6f8a6aa9d54a762ad8796872681a
Parents: ecda834
Author: Vijay Parthasarathy vijay2...@gmail.com
Authored: Thu Jun 21 21:20:09 2012 -0700
Committer: Vijay Parthasarathy vijay2...@gmail.com
Committed: Thu Jun 21 21:20:09 2012 -0700
--
.../org/apache/cassandra/service/StorageProxy.java | 66 ++-
1 files changed, 45 insertions(+), 21 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9cf915fd/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 92a3256..4353a8f 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -845,6 +845,22 @@ public class StorageProxy implements StorageProxyMBean
int columnsCount = 0;
rows = new ArrayListRow();
ListAbstractBoundsRowPosition ranges =
getRestrictedRanges(command.range);
+
+// get the cardinality of this index based on row count
+// use this info to decide how many scans to do in parallel
+long estimatedKeys =
Table.open(command.keyspace).getColumnFamilyStore(command.column_family)
+.estimateKeys();
+int concurrencyFactor = (int) command.maxResults / ((int)
estimatedKeys + 1);
+
+if (concurrencyFactor = 0)
+concurrencyFactor = 1;
+
+if (concurrencyFactor ranges.size())
+concurrencyFactor = ranges.size();
+
+// parallel scan handlers
+ListReadCallbackRangeSliceReply, IterableRow scanHandlers =
new ArrayListReadCallbackRangeSliceReply, IterableRow(concurrencyFactor);
+
for (AbstractBoundsRowPosition range : ranges)
{
RangeSliceCommand nodeCmd = new
RangeSliceCommand(command.keyspace,
@@ -895,32 +911,40 @@ public class StorageProxy implements StorageProxyMBean
logger.debug(reading + nodeCmd + from +
endpoint);
}
-try
+scanHandlers.add(handler);
+if (scanHandlers.size() = concurrencyFactor)
{
-for (Row row : handler.get())
+for (ReadCallbackRangeSliceReply, IterableRow
scanHandler : scanHandlers)
{
-rows.add(row);
-columnsCount += row.getLiveColumnCount();
-logger.debug(range slices read {}, row.key);
+try
+{
+for (Row row : scanHandler.get())
+{
+rows.add(row);
+columnsCount += row.getLiveColumnCount();
+logger.debug(range slices read {},
row.key);
+}
+
FBUtilities.waitOnFutures(resolver.repairResults,
DatabaseDescriptor.getReadRpcTimeout());
+}
+catch (TimeoutException ex)
+{
+if (logger.isDebugEnabled())
+logger.debug(Range slice timeout: {},
ex.toString());
+throw ex;
+}
+catch (DigestMismatchException e)
+{
+throw new AssertionError(e); // no digests in
range slices yet
+}
+
+// if we're done, great, otherwise, move to the
next range
+int count = nodeCmd.maxIsColumns ? columnsCount :
rows.size();
+if (count = nodeCmd.maxResults)
+break;
}
-FBUtilities.waitOnFutures(resolver.repairResults,
DatabaseDescriptor.getWriteRpcTimeout());
-}
-catch (TimeoutException ex)
-
