[jira] [Commented] (CASSANDRA-4427) Restarting a failed bootstrap instajoins the ring
[ https://issues.apache.org/jira/browse/CASSANDRA-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416921#comment-13416921 ] Jonathan Ellis commented on CASSANDRA-4427: --- bq. I believe this simpler fix doesn't handle the case of boostrapping multiple nodes into an existing cluster. We've never tried to prevent this, except by saying thou shalt space bootstraps apart two minutes, because the only way to stop it is to drop the balanced token picking altogether. Adding bootstrap in progress concept does nothing for this one way or the other. bq. Namely, in that case, that will have a schema and so the node will have a system table by the time it checks for it and we'll end up picking the same token for multiple nodes. This is exactly how it's supposed to work: if there's a schema, we use existing cluster mode and pick a token to divide the range of the heaviest node (and cross our fingers that the user is spacing things out enough between node additions). If there's no schema, we use new cluster mode and pick a random token. Let the record show that back in CASSANDRA-3219 I said this was confusing behavior and we should add explicit initial_token modes instead of trying to make it magical. :) Restarting a failed bootstrap instajoins the ring - Key: CASSANDRA-4427 URL: https://issues.apache.org/jira/browse/CASSANDRA-4427 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Jonathan Ellis Fix For: 1.0.11, 1.1.3 Attachments: 4427-v2.txt, 4427-v3.txt, 4427.txt I think when we made auto_bootstrap = true the default, we broke the check for the bootstrap flag, creating a dangerous situation. -- 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-4427) Restarting a failed bootstrap instajoins the ring
[ https://issues.apache.org/jira/browse/CASSANDRA-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416921#comment-13416921 ] Jonathan Ellis edited comment on CASSANDRA-4427 at 7/18/12 7:35 AM: bq. I believe this simpler fix doesn't handle the case of boostrapping multiple nodes into an existing cluster. We've never tried to prevent this in the existing cluster case, except by saying thou shalt space bootstraps apart two minutes, because the only way to stop it is to drop the balanced token picking altogether. Adding bootstrap in progress concept does nothing for this one way or the other. bq. Namely, in that case, that will have a schema and so the node will have a system table by the time it checks for it and we'll end up picking the same token for multiple nodes. This is exactly how it's supposed to work: if there's a schema, we use existing cluster mode and pick a token to divide the range of the heaviest node (and cross our fingers that the user is spacing things out enough between node additions). If there's no schema, we use new cluster mode and pick a random token. Let the record show that back in CASSANDRA-3219 I said this was confusing behavior and we should add explicit initial_token modes instead of trying to make it magical. :) was (Author: jbellis): bq. I believe this simpler fix doesn't handle the case of boostrapping multiple nodes into an existing cluster. We've never tried to prevent this, except by saying thou shalt space bootstraps apart two minutes, because the only way to stop it is to drop the balanced token picking altogether. Adding bootstrap in progress concept does nothing for this one way or the other. bq. Namely, in that case, that will have a schema and so the node will have a system table by the time it checks for it and we'll end up picking the same token for multiple nodes. This is exactly how it's supposed to work: if there's a schema, we use existing cluster mode and pick a token to divide the range of the heaviest node (and cross our fingers that the user is spacing things out enough between node additions). If there's no schema, we use new cluster mode and pick a random token. Let the record show that back in CASSANDRA-3219 I said this was confusing behavior and we should add explicit initial_token modes instead of trying to make it magical. :) Restarting a failed bootstrap instajoins the ring - Key: CASSANDRA-4427 URL: https://issues.apache.org/jira/browse/CASSANDRA-4427 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Jonathan Ellis Fix For: 1.0.11, 1.1.3 Attachments: 4427-v2.txt, 4427-v3.txt, 4427.txt I think when we made auto_bootstrap = true the default, we broke the check for the bootstrap flag, creating a dangerous situation. -- 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-4435) hints compaction loop over same sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-4435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4435:
--
Attachment: 4435-v2.txt
Can we just use the existing isCompactionDisabled logic? v2 attached
hints compaction loop over same sstable
---
Key: CASSANDRA-4435
URL: https://issues.apache.org/jira/browse/CASSANDRA-4435
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2
Reporter: Brandon Williams
Assignee: Yuki Morishita
Labels: compaction, hintedhandoff
Attachments: 4435-v2.txt, 4435.txt
Noticed the following while testing something else:
{noformat}
INFO 22:14:48,496 Completed flushing
/var/lib/cassandra/data/system/hints/system-hints-ia-1-Data.db (109645 bytes)
for commitlog position ReplayPosition(segmentId=9372773011543415,
position=30358488)
INFO 22:14:48,498 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-1-Data.db')]
INFO 22:14:48,500 SSTables for user defined compaction are already being
compacted.
INFO 22:14:48,500 Finished hinted handoff of 16893 rows to endpoint
/10.179.64.227
INFO 22:14:48,658 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-2-Data.db,]. 109,645
to 899 (~0% of original) bytes for 1 keys at 0.005392MB/s. Time: 159ms.
INFO 22:14:48,660 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-2-Data.db')]
INFO 22:14:48,668 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-3-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.107169MB/s. Time: 8ms.
INFO 22:14:48,669 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-3-Data.db')]
INFO 22:14:48,679 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-4-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.095261MB/s. Time: 9ms.
INFO 22:14:48,680 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-4-Data.db')]
INFO 22:14:48,697 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-5-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.050433MB/s. Time: 17ms.
INFO 22:14:48,698 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-5-Data.db')]
INFO 22:14:48,714 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-6-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.053585MB/s. Time: 16ms.
INFO 22:14:48,715 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-6-Data.db')]
INFO 22:14:48,722 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-7-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,723 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-7-Data.db')]
INFO 22:14:48,736 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-8-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.065950MB/s. Time: 13ms.
INFO 22:14:48,737 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-8-Data.db')]
INFO 22:14:48,744 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-9-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,745 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-9-Data.db')]
INFO 22:14:48,753 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-10-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,754 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-10-Data.db')]
INFO 22:14:48,761 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-11-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,762 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-11-Data.db')]
INFO 22:14:48,775 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-12-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.065950MB/s. Time: 13ms.
INFO 22:14:48,776 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-12-Data.db')]
INFO 22:14:48,783 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-13-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,784 Compacting
[jira] [Commented] (CASSANDRA-4275) Oracle Java 1.7 u4 does not allow Xss128k
[ https://issues.apache.org/jira/browse/CASSANDRA-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416924#comment-13416924 ] Jonathan Ellis commented on CASSANDRA-4275: --- Should probably open a new ticket either way since we committed the original for 1.1.2. Oracle Java 1.7 u4 does not allow Xss128k - Key: CASSANDRA-4275 URL: https://issues.apache.org/jira/browse/CASSANDRA-4275 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.9, 1.1.0 Reporter: Edward Capriolo Assignee: Sylvain Lebresne Fix For: 1.1.2 Attachments: 4275.txt, trunk-cassandra-4275.1.patch.txt, v1-0001-CASSANDRA-4275-Use-JVM-s-reported-minimum-stack-size-o.txt Problem: This happens when you try to start it with default Xss setting of 128k === The stack size specified is too small, Specify at least 160k Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Solution === Set -Xss to 256k Problem: This happens when you try to start it with Xss = 160k ERROR [Thrift:14] 2012-05-22 14:42:40,479 AbstractCassandraDaemon.java (line 139) Fatal exception in thread Thread[Thrift:14,5,main] java.lang.StackOverflowError Solution === Set -Xss to 256k -- 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-4427) Restarting a failed bootstrap instajoins the ring
[ https://issues.apache.org/jira/browse/CASSANDRA-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416945#comment-13416945 ] Sylvain Lebresne commented on CASSANDRA-4427: - bq. Adding bootstrap in progress concept does nothing for this one way or the other. You're right, brain fart, sorry. Anyway, there is still one behavior that the patch changes, that is it will always boobstrap non seeds node, while previously the system table check was making sure we never bootstrapped a node in a new cluster, independently of whether it was a seed or not. It is clearly not a bad idea when you start a new cluster to set all those nodes as seeds, but I just want to point out that the behavior is changed and I'm not sure everyone always set all of its initial node as seeds today. I'll also note that boostrapping some of the node in an initial cluster don't break anything, it just makes the node start much less quickly that they would otherwise. I'm not sure how I feel about changing that behavior, especially in a minor release. The fact is that recording that bootstrap is in progress (along with the system table check) would allow to fix the instajoin while keeping the current behavior unchanged otherwise, and I do feel that recording the info is not a bad idea in itself, so that would have my preference. But that is not an extremely strong preference either. Restarting a failed bootstrap instajoins the ring - Key: CASSANDRA-4427 URL: https://issues.apache.org/jira/browse/CASSANDRA-4427 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Jonathan Ellis Fix For: 1.0.11, 1.1.3 Attachments: 4427-v2.txt, 4427-v3.txt, 4427.txt I think when we made auto_bootstrap = true the default, we broke the check for the bootstrap flag, creating a dangerous situation. -- 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-4436) Counters in columns don't preserve correct values after cluster restart
[ https://issues.apache.org/jira/browse/CASSANDRA-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne reassigned CASSANDRA-4436: --- Assignee: Sylvain Lebresne Counters in columns don't preserve correct values after cluster restart --- Key: CASSANDRA-4436 URL: https://issues.apache.org/jira/browse/CASSANDRA-4436 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.10 Reporter: Peter Velas Assignee: Sylvain Lebresne Attachments: increments.cql.gz Similar to #3821. but affecting normal columns. Set up a 2-node cluster with rf=2. 1. Create a counter column family and increment a 100 keys in loop 5000 times. 2. Then make a rolling restart to cluster. 3. Again increment another 5000 times. 4. Make a rolling restart to cluster. 5. Again increment another 5000 times. 6. Make a rolling restart to cluster. After step 6 we were able to reproduce bug with bad counter values. Expected values were 15 000. Values returned from cluster are higher then 15000 + some random number. Rolling restarts are done with nodetool drain. Always waiting until second node discover its down then kill java process. -- 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-4272) Keyspace name case sensitivity
[
https://issues.apache.org/jira/browse/CASSANDRA-4272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416954#comment-13416954
]
Jure Koren commented on CASSANDRA-4272:
---
I don't think recreating a cluster is a good enough solution for this. I have
the same problem and can't recreate an empty cluster.
Is there a way to prune deleted keys from the system keyspace? I can still list
deleted keyspaces from the schema_keyspaces CF in the system keyspace, perhaps
that's what causes problems.
Keyspace name case sensitivity
--
Key: CASSANDRA-4272
URL: https://issues.apache.org/jira/browse/CASSANDRA-4272
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Environment: cassandra-cli
Reporter: Claudio Atzori
I've been trying to define a keyspace from the cassandra-cli on a cluster of
5 nodes (1.1.0), but I got a NotFoundException(), after a schema agreement
accross the cluster message, which I guess It can be quite confusing, because
the keyspace wasn't created at all.
[default@unknown] create keyspace 'MY_NEW_KEYSPACE' with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2} ;
ba6a9a70-e983-3b9c-bd8c-b0022865bb3e
Waiting for schema agreement...
... schemas agree across the cluster
NotFoundException()
BTW, I've been able to create the keyspace by lowercasing its name.
--
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-4272) Keyspace name case sensitivity
[
https://issues.apache.org/jira/browse/CASSANDRA-4272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416954#comment-13416954
]
Jure Koren edited comment on CASSANDRA-4272 at 7/18/12 9:15 AM:
I don't think recreating a cluster is a good enough solution for this. I have
the same problem and can't recreate an empty cluster.
Is there a way to prune deleted keys from the system keyspace? I can still list
deleted keyspaces from the schema_keyspaces CF in the system keyspace, perhaps
that's what causes problems.
I could create a keyspace with the same name, but different case before, but
this doesn't work anymore:
[default@unknown] create keyspace test_Campaigns with placement_strategy =
'NetworkTopologyStrategy' and strategy_options = {DC_KOT : 1, DC_DELO : 1,
DC_OFC : 1} and durable_writes = true;
62979db5-8643-31ad-b13a-289e66d8f414
Waiting for schema agreement...
... schemas agree across the cluster
NotFoundException()
[default@unknown] create keyspace test_campaigns with placement_strategy =
'NetworkTopologyStrategy' and strategy_options = {DC_KOT : 1, DC_DELO : 1,
DC_OFC : 1} and durable_writes = true;
62979db5-8643-31ad-b13a-289e66d8f414
Waiting for schema agreement...
... schemas agree across the cluster
NotFoundException()
was (Author: jurek):
I don't think recreating a cluster is a good enough solution for this. I
have the same problem and can't recreate an empty cluster.
Is there a way to prune deleted keys from the system keyspace? I can still list
deleted keyspaces from the schema_keyspaces CF in the system keyspace, perhaps
that's what causes problems.
Keyspace name case sensitivity
--
Key: CASSANDRA-4272
URL: https://issues.apache.org/jira/browse/CASSANDRA-4272
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Environment: cassandra-cli
Reporter: Claudio Atzori
I've been trying to define a keyspace from the cassandra-cli on a cluster of
5 nodes (1.1.0), but I got a NotFoundException(), after a schema agreement
accross the cluster message, which I guess It can be quite confusing, because
the keyspace wasn't created at all.
[default@unknown] create keyspace 'MY_NEW_KEYSPACE' with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2} ;
ba6a9a70-e983-3b9c-bd8c-b0022865bb3e
Waiting for schema agreement...
... schemas agree across the cluster
NotFoundException()
BTW, I've been able to create the keyspace by lowercasing its name.
--
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-4427) Restarting a failed bootstrap instajoins the ring
[ https://issues.apache.org/jira/browse/CASSANDRA-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417016#comment-13417016 ] Brandon Williams commented on CASSANDRA-4427: - bq. The fact is that recording that bootstrap is in progress (along with the system table check) would allow to fix the instajoin while keeping the current behavior unchanged otherwise, and I do feel that recording the info is not a bad idea in itself, so that would have my preference. I tend to agree that having an explicit, persisted flag feels a lot less fragile than the current logic, and being able to indicate a failure to the user seems like a good improvement. Restarting a failed bootstrap instajoins the ring - Key: CASSANDRA-4427 URL: https://issues.apache.org/jira/browse/CASSANDRA-4427 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Jonathan Ellis Fix For: 1.0.11, 1.1.3 Attachments: 4427-v2.txt, 4427-v3.txt, 4427.txt I think when we made auto_bootstrap = true the default, we broke the check for the bootstrap flag, creating a dangerous situation. -- 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-4411) Assertion with LCS compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417024#comment-13417024
]
Omid Aladini commented on CASSANDRA-4411:
-
Awesome. Thanks for the patch. Tested it and it works.
Sylvain, regarding your earlier comment on CASSANDRA-4321:
{quote} This is not really a new bug, but I believe that prior to
CASSANDRA-4142, this had less consequences. {quote}
Does it mean LC-compacted SSTables created by 1.1.0 or earlier are as well
affected and need to be scrubbed?
Assertion with LCS compaction
-
Key: CASSANDRA-4411
URL: https://issues.apache.org/jira/browse/CASSANDRA-4411
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Reporter: Anton Winter
Assignee: Sylvain Lebresne
Fix For: 1.1.3
Attachments: 0001-Add-debugging-info-for-LCS.txt, 4411-followup.txt,
4411.txt, assertion-w-more-debugging-info-omid.log,
assertion.moreinfo.system.log, system.log
As instructed in CASSANDRA-4321 I have raised this issue as a continuation of
that issue as it appears the problem still exists.
I have repeatedly run sstablescrub across all my nodes after the 1.1.2
upgrade until sstablescrub shows no errors. The exceptions described in
CASSANDRA-4321 do not occur as frequently now but the integrity check still
throws exceptions on a number of nodes. Once those exceptions occur
compactionstats shows a large number of pending tasks with no progression
afterwards.
{code}
ERROR [CompactionExecutor:150] 2012-07-05 04:26:15,570
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[CompactionExecutor:150,1,main]
java.lang.AssertionError
at
org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:214)
at
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:158)
at
org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:531)
at
org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:254)
at
org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:978)
at
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:200)
at
org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:50)
at
org.apache.cassandra.db.compaction.CompactionManager$1.runMayThrow(CompactionManager.java:150)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{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
[jira] [Updated] (CASSANDRA-4049) Add generic way of adding SSTable components required custom compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Kołaczkowski updated CASSANDRA-4049: -- Attachment: pluggable_custom_components.patch Add generic way of adding SSTable components required custom compaction strategy Key: CASSANDRA-4049 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Piotr Kołaczkowski Assignee: Piotr Kołaczkowski Priority: Minor Labels: compaction Fix For: 1.1.3 Attachments: pluggable_custom_components.patch CFS compaction strategy coming up in the next DSE release needs to store some important information in Tombstones.db and RemovedKeys.db files, one per sstable. However, currently Cassandra issues warnings when these files are found in the data directory. Additionally, when switched to SizeTieredCompactionStrategy, the files are left in the data directory after compaction. The attached patch adds new components to the Component class so Cassandra knows about those files. -- 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-4049) Add generic way of adding SSTable components required custom compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Kołaczkowski updated CASSANDRA-4049: -- Attachment: (was: compaction_strategy_cleanup.patch) Add generic way of adding SSTable components required custom compaction strategy Key: CASSANDRA-4049 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Piotr Kołaczkowski Assignee: Piotr Kołaczkowski Priority: Minor Labels: compaction Fix For: 1.1.3 Attachments: pluggable_custom_components.patch CFS compaction strategy coming up in the next DSE release needs to store some important information in Tombstones.db and RemovedKeys.db files, one per sstable. However, currently Cassandra issues warnings when these files are found in the data directory. Additionally, when switched to SizeTieredCompactionStrategy, the files are left in the data directory after compaction. The attached patch adds new components to the Component class so Cassandra knows about those files. -- 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-4049) Add generic way of adding SSTable components required custom compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Kołaczkowski updated CASSANDRA-4049: -- Attachment: (was: component_patch.diff) Add generic way of adding SSTable components required custom compaction strategy Key: CASSANDRA-4049 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Piotr Kołaczkowski Assignee: Piotr Kołaczkowski Priority: Minor Labels: compaction Fix For: 1.1.3 Attachments: pluggable_custom_components.patch CFS compaction strategy coming up in the next DSE release needs to store some important information in Tombstones.db and RemovedKeys.db files, one per sstable. However, currently Cassandra issues warnings when these files are found in the data directory. Additionally, when switched to SizeTieredCompactionStrategy, the files are left in the data directory after compaction. The attached patch adds new components to the Component class so Cassandra knows about those files. -- 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-4435) hints compaction loop over same sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-4435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-4435:
--
Attachment: 4435-v3.txt
Yes it works, except your syntax doesn't work. Attaching v3.
hints compaction loop over same sstable
---
Key: CASSANDRA-4435
URL: https://issues.apache.org/jira/browse/CASSANDRA-4435
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2
Reporter: Brandon Williams
Assignee: Yuki Morishita
Labels: compaction, hintedhandoff
Attachments: 4435-v2.txt, 4435-v3.txt, 4435.txt
Noticed the following while testing something else:
{noformat}
INFO 22:14:48,496 Completed flushing
/var/lib/cassandra/data/system/hints/system-hints-ia-1-Data.db (109645 bytes)
for commitlog position ReplayPosition(segmentId=9372773011543415,
position=30358488)
INFO 22:14:48,498 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-1-Data.db')]
INFO 22:14:48,500 SSTables for user defined compaction are already being
compacted.
INFO 22:14:48,500 Finished hinted handoff of 16893 rows to endpoint
/10.179.64.227
INFO 22:14:48,658 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-2-Data.db,]. 109,645
to 899 (~0% of original) bytes for 1 keys at 0.005392MB/s. Time: 159ms.
INFO 22:14:48,660 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-2-Data.db')]
INFO 22:14:48,668 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-3-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.107169MB/s. Time: 8ms.
INFO 22:14:48,669 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-3-Data.db')]
INFO 22:14:48,679 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-4-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.095261MB/s. Time: 9ms.
INFO 22:14:48,680 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-4-Data.db')]
INFO 22:14:48,697 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-5-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.050433MB/s. Time: 17ms.
INFO 22:14:48,698 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-5-Data.db')]
INFO 22:14:48,714 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-6-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.053585MB/s. Time: 16ms.
INFO 22:14:48,715 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-6-Data.db')]
INFO 22:14:48,722 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-7-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,723 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-7-Data.db')]
INFO 22:14:48,736 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-8-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.065950MB/s. Time: 13ms.
INFO 22:14:48,737 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-8-Data.db')]
INFO 22:14:48,744 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-9-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,745 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-9-Data.db')]
INFO 22:14:48,753 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-10-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,754 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-10-Data.db')]
INFO 22:14:48,761 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-11-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,762 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-11-Data.db')]
INFO 22:14:48,775 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-12-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.065950MB/s. Time: 13ms.
INFO 22:14:48,776 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-12-Data.db')]
INFO 22:14:48,783 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-13-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,784 Compacting
[2/3] git commit: Merge branch 'p/4125/01_admin_tools' into refs/top-bases/p/4127/01_migration_path
Merge branch 'p/4125/01_admin_tools' into refs/top-bases/p/4127/01_migration_path Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7f4bdb43 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7f4bdb43 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7f4bdb43 Branch: refs/heads/vnodes Commit: 7f4bdb4338a3e05948239c5edf89a11011dc2e2f Parents: d09c369 c0a7c03 Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 10:32:17 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 10:32:17 2012 -0500 -- .../apache/cassandra/service/StorageService.java | 25 --- 1 files changed, 0 insertions(+), 25 deletions(-) --
[1/3] git commit: Merge commit 'refs/top-bases/p/4127/01_migration_path' into p/4127/01_migration_path
Updated Branches: refs/heads/vnodes 6eac7e650 - 72e98326d Merge commit 'refs/top-bases/p/4127/01_migration_path' into p/4127/01_migration_path Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/72e98326 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/72e98326 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/72e98326 Branch: refs/heads/vnodes Commit: 72e98326dbac87bd22f8d16f61fec6c07c496a84 Parents: 6eac7e6 7f4bdb4 Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 10:32:17 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 10:32:17 2012 -0500 -- .../apache/cassandra/service/StorageService.java | 25 --- 1 files changed, 0 insertions(+), 25 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/72e98326/src/java/org/apache/cassandra/service/StorageService.java --
[3/3] git commit: remove dead code
remove dead code
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c0a7c032
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c0a7c032
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c0a7c032
Branch: refs/heads/vnodes
Commit: c0a7c032c86d266d6a1d28edcd3c116909cf7d31
Parents: 8821e8b
Author: Eric Evans eev...@apache.org
Authored: Wed Jul 18 10:31:56 2012 -0500
Committer: Eric Evans eev...@apache.org
Committed: Wed Jul 18 10:31:56 2012 -0500
--
.../apache/cassandra/service/StorageService.java | 25 ---
1 files changed, 0 insertions(+), 25 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c0a7c032/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 99fbd84..b5d6d20 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -2882,31 +2882,6 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
// calculate ownership per dc
for (CollectionInetAddress endpoints : endpointsGroupedByDc)
{
-// sort the endpoints by their tokens
-ListInetAddress sortedEndpoints =
Lists.newArrayListWithExpectedSize(endpoints.size());
-sortedEndpoints.addAll(endpoints);
-
-Collections.sort(sortedEndpoints, new ComparatorInetAddress()
-{
-public int compare(InetAddress o1, InetAddress o2)
-{
-byte[] b1 = o1.getAddress();
-byte[] b2 = o2.getAddress();
-
-if(b1.length b2.length) return -1;
-if(b1.length b2.length) return 1;
-
-for(int i = 0; i b1.length; i++)
-{
-int left = (int)b1[i] 0xFF;
-int right = (int)b2[i] 0xFF;
-if (left right) return -1;
-else if (left right) return 1;
-}
-return 0;
-}
-});
-
// calculate the ownership with replication and add the endpoint
to the final ownership map
for (InetAddress endpoint : endpoints)
{
[jira] [Created] (CASSANDRA-4442) Stack size settings in cassandra-env.sh assume 64-bit x86
Trevor Robinson created CASSANDRA-4442: -- Summary: Stack size settings in cassandra-env.sh assume 64-bit x86 Key: CASSANDRA-4442 URL: https://issues.apache.org/jira/browse/CASSANDRA-4442 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.2 Reporter: Trevor Robinson The fix for CASSANDRA-4275 hard-codes a 160 KB stack size when using Java 7 on Linux. This assumes the Oracle 7u4 JVM on 64-bit x86. For systems like 32-bit ARM, this size is excessive (the minimum for 7u4 on ARM is 60-64 KB). Also, the minimum allowed value is version-dependent and is calculated dynamically by the JVM on startup based on Linux parameters that can also change. A better approach would be to query the JVM for the minimum stack size. -- 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-4442) Stack size settings in cassandra-env.sh assume 64-bit x86
[ https://issues.apache.org/jira/browse/CASSANDRA-4442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Robinson updated CASSANDRA-4442: --- Attachment: v1-0001-CASSANDRA-4275-Use-JVM-s-reported-minimum-stack-size-o.txt The attached patch was tested with Oracle 7u4 and OpenJDK 6u24 on amd64, and Oracle 7u4 on ARMv7. Reported stack sizes of 160k, 104k, and 64k, respectively. Just tested startup on amd64, but ran 'stress -o insert' on ARM. Note that the patch also fixes an issue with CASSANDRA-4366 (UseCondCardMark) where JDK 1.7 was only detected on Linux. Stack size settings in cassandra-env.sh assume 64-bit x86 - Key: CASSANDRA-4442 URL: https://issues.apache.org/jira/browse/CASSANDRA-4442 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.2 Reporter: Trevor Robinson Attachments: v1-0001-CASSANDRA-4275-Use-JVM-s-reported-minimum-stack-size-o.txt The fix for CASSANDRA-4275 hard-codes a 160 KB stack size when using Java 7 on Linux. This assumes the Oracle 7u4 JVM on 64-bit x86. For systems like 32-bit ARM, this size is excessive (the minimum for 7u4 on ARM is 60-64 KB). Also, the minimum allowed value is version-dependent and is calculated dynamically by the JVM on startup based on Linux parameters that can also change. A better approach would be to query the JVM for the minimum stack size. -- 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-4411) Assertion with LCS compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417234#comment-13417234
]
Sylvain Lebresne commented on CASSANDRA-4411:
-
bq. Does it mean LC-compacted SSTables created by 1.1.0 or earlier are as well
affected and need to be scrubbed?
Potentially, yes, unfortunately.
Assertion with LCS compaction
-
Key: CASSANDRA-4411
URL: https://issues.apache.org/jira/browse/CASSANDRA-4411
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Reporter: Anton Winter
Assignee: Sylvain Lebresne
Fix For: 1.1.3
Attachments: 0001-Add-debugging-info-for-LCS.txt, 4411-followup.txt,
4411.txt, assertion-w-more-debugging-info-omid.log,
assertion.moreinfo.system.log, system.log
As instructed in CASSANDRA-4321 I have raised this issue as a continuation of
that issue as it appears the problem still exists.
I have repeatedly run sstablescrub across all my nodes after the 1.1.2
upgrade until sstablescrub shows no errors. The exceptions described in
CASSANDRA-4321 do not occur as frequently now but the integrity check still
throws exceptions on a number of nodes. Once those exceptions occur
compactionstats shows a large number of pending tasks with no progression
afterwards.
{code}
ERROR [CompactionExecutor:150] 2012-07-05 04:26:15,570
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[CompactionExecutor:150,1,main]
java.lang.AssertionError
at
org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:214)
at
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:158)
at
org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:531)
at
org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:254)
at
org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:978)
at
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:200)
at
org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:50)
at
org.apache.cassandra.db.compaction.CompactionManager$1.runMayThrow(CompactionManager.java:150)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{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
[4/4] git commit: align for load of format ###.##
align for load of format ###.##
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/98250a95
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/98250a95
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/98250a95
Branch: refs/heads/vnodes
Commit: 98250a95584c479e54cb8440657ec9ef12e347b5
Parents: c0a7c03
Author: Eric Evans eev...@apache.org
Authored: Wed Jul 18 12:18:49 2012 -0500
Committer: Eric Evans eev...@apache.org
Committed: Wed Jul 18 12:18:49 2012 -0500
--
src/java/org/apache/cassandra/tools/NodeCmd.java |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/98250a95/src/java/org/apache/cassandra/tools/NodeCmd.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java
b/src/java/org/apache/cassandra/tools/NodeCmd.java
index 0da3381..b0c9f7d 100644
--- a/src/java/org/apache/cassandra/tools/NodeCmd.java
+++ b/src/java/org/apache/cassandra/tools/NodeCmd.java
@@ -391,7 +391,7 @@ public class NodeCmd
if (format == null)
{
StringBuffer buf = new StringBuffer();
-buf.append(%s%s %-16s %-8s );// status,
address, and load
+buf.append(%s%s %-16s %-9s );// status,
address, and load
if (!isTokenPerNode) buf.append(%-6s ); // Tokens
if (hasEffectiveOwns) buf.append(%-16s ); // Owns
(effective)
else buf.append(%-5s ); // Owns
[2/4] git commit: Merge branch 'p/4125/01_admin_tools' into refs/top-bases/p/4127/01_migration_path
Merge branch 'p/4125/01_admin_tools' into refs/top-bases/p/4127/01_migration_path Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/875c8ff4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/875c8ff4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/875c8ff4 Branch: refs/heads/vnodes Commit: 875c8ff4f702452ada2abf38b5b6dfc18bda7c9e Parents: 7f4bdb4 606adeb Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 12:25:38 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 12:25:38 2012 -0500 -- src/java/org/apache/cassandra/tools/NodeCmd.java |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) --
[3/4] git commit: change column header from + to -; bikeshed color from red to blue
change column header from + to -; bikeshed color from red to blue Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/606adeb0 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/606adeb0 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/606adeb0 Branch: refs/heads/vnodes Commit: 606adeb067d994398444e4e8104325e8a8636472 Parents: 98250a9 Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 12:24:51 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 12:24:51 2012 -0500 -- src/java/org/apache/cassandra/tools/NodeCmd.java |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/606adeb0/src/java/org/apache/cassandra/tools/NodeCmd.java -- diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java b/src/java/org/apache/cassandra/tools/NodeCmd.java index b0c9f7d..9fff6c5 100644 --- a/src/java/org/apache/cassandra/tools/NodeCmd.java +++ b/src/java/org/apache/cassandra/tools/NodeCmd.java @@ -441,9 +441,9 @@ public class NodeCmd String owns = hasEffectiveOwns ? Owns (effective) : Owns; if (isTokenPerNode) -outs.printf(fmt, +, +, Address, Load, owns, Host ID, Token, Rack); +outs.printf(fmt, -, -, Address, Load, owns, Host ID, Token, Rack); else -outs.printf(fmt, +, +, Address, Load, Tokens, owns, Host ID, Rack); +outs.printf(fmt, -, -, Address, Load, Tokens, owns, Host ID, Rack); } void print() throws UnknownHostException
[1/4] git commit: Merge commit 'refs/top-bases/p/4127/01_migration_path' into p/4127/01_migration_path
Updated Branches: refs/heads/vnodes 72e98326d - 4352f7936 Merge commit 'refs/top-bases/p/4127/01_migration_path' into p/4127/01_migration_path Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4352f793 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4352f793 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4352f793 Branch: refs/heads/vnodes Commit: 4352f79365ce0d822d73ac84ec22b0e699660276 Parents: 72e9832 875c8ff Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 12:25:38 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 12:25:38 2012 -0500 -- src/java/org/apache/cassandra/tools/NodeCmd.java |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) --
[jira] [Commented] (CASSANDRA-4435) hints compaction loop over same sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-4435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417275#comment-13417275
]
Jonathan Ellis commented on CASSANDRA-4435:
---
+1
hints compaction loop over same sstable
---
Key: CASSANDRA-4435
URL: https://issues.apache.org/jira/browse/CASSANDRA-4435
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2
Reporter: Brandon Williams
Assignee: Yuki Morishita
Labels: compaction, hintedhandoff
Attachments: 4435-v2.txt, 4435-v3.txt, 4435.txt
Noticed the following while testing something else:
{noformat}
INFO 22:14:48,496 Completed flushing
/var/lib/cassandra/data/system/hints/system-hints-ia-1-Data.db (109645 bytes)
for commitlog position ReplayPosition(segmentId=9372773011543415,
position=30358488)
INFO 22:14:48,498 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-1-Data.db')]
INFO 22:14:48,500 SSTables for user defined compaction are already being
compacted.
INFO 22:14:48,500 Finished hinted handoff of 16893 rows to endpoint
/10.179.64.227
INFO 22:14:48,658 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-2-Data.db,]. 109,645
to 899 (~0% of original) bytes for 1 keys at 0.005392MB/s. Time: 159ms.
INFO 22:14:48,660 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-2-Data.db')]
INFO 22:14:48,668 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-3-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.107169MB/s. Time: 8ms.
INFO 22:14:48,669 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-3-Data.db')]
INFO 22:14:48,679 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-4-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.095261MB/s. Time: 9ms.
INFO 22:14:48,680 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-4-Data.db')]
INFO 22:14:48,697 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-5-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.050433MB/s. Time: 17ms.
INFO 22:14:48,698 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-5-Data.db')]
INFO 22:14:48,714 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-6-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.053585MB/s. Time: 16ms.
INFO 22:14:48,715 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-6-Data.db')]
INFO 22:14:48,722 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-7-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,723 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-7-Data.db')]
INFO 22:14:48,736 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-8-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.065950MB/s. Time: 13ms.
INFO 22:14:48,737 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-8-Data.db')]
INFO 22:14:48,744 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-9-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,745 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-9-Data.db')]
INFO 22:14:48,753 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-10-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,754 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-10-Data.db')]
INFO 22:14:48,761 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-11-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,762 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-11-Data.db')]
INFO 22:14:48,775 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-12-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.065950MB/s. Time: 13ms.
INFO 22:14:48,776 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-12-Data.db')]
INFO 22:14:48,783 Compacted to
[/var/lib/cassandra/data/system/hints/system-hints-ia-13-Data.db,]. 899 to
899 (~100% of original) bytes for 1 keys at 0.122479MB/s. Time: 7ms.
INFO 22:14:48,784 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/hints/system-hints-ia-13-Data.db')]
INFO
[jira] [Updated] (CASSANDRA-4442) Stack size settings in cassandra-env.sh assume 64-bit x86
[ https://issues.apache.org/jira/browse/CASSANDRA-4442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4442: -- Reviewer: brandon.williams Stack size settings in cassandra-env.sh assume 64-bit x86 - Key: CASSANDRA-4442 URL: https://issues.apache.org/jira/browse/CASSANDRA-4442 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.2 Reporter: Trevor Robinson Fix For: 1.1.3 Attachments: v1-0001-CASSANDRA-4275-Use-JVM-s-reported-minimum-stack-size-o.txt The fix for CASSANDRA-4275 hard-codes a 160 KB stack size when using Java 7 on Linux. This assumes the Oracle 7u4 JVM on 64-bit x86. For systems like 32-bit ARM, this size is excessive (the minimum for 7u4 on ARM is 60-64 KB). Also, the minimum allowed value is version-dependent and is calculated dynamically by the JVM on startup based on Linux parameters that can also change. A better approach would be to query the JVM for the minimum stack size. -- 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-4442) Stack size settings in cassandra-env.sh assume 64-bit x86
[ https://issues.apache.org/jira/browse/CASSANDRA-4442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4442: -- Fix Version/s: 1.1.3 Stack size settings in cassandra-env.sh assume 64-bit x86 - Key: CASSANDRA-4442 URL: https://issues.apache.org/jira/browse/CASSANDRA-4442 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.2 Reporter: Trevor Robinson Fix For: 1.1.3 Attachments: v1-0001-CASSANDRA-4275-Use-JVM-s-reported-minimum-stack-size-o.txt The fix for CASSANDRA-4275 hard-codes a 160 KB stack size when using Java 7 on Linux. This assumes the Oracle 7u4 JVM on 64-bit x86. For systems like 32-bit ARM, this size is excessive (the minimum for 7u4 on ARM is 60-64 KB). Also, the minimum allowed value is version-dependent and is calculated dynamically by the JVM on startup based on Linux parameters that can also change. A better approach would be to query the JVM for the minimum stack size. -- 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-4443) balance/shuffle utility for vnodes
Brandon Williams created CASSANDRA-4443: --- Summary: balance/shuffle utility for vnodes Key: CASSANDRA-4443 URL: https://issues.apache.org/jira/browse/CASSANDRA-4443 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2 Reporter: Brandon Williams Fix For: 1.2 As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to split up the contiguous ranges. In addition, we still need a 'balance' utility similar to move without a token, in the cases where entropy is not your friend and gives you an unbalanced cluster (I've seen up to a 7% discrepancy myself) -- 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-4443) balance/shuffle utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4443: Issue Type: New Feature (was: Bug) balance/shuffle utility for vnodes -- Key: CASSANDRA-4443 URL: https://issues.apache.org/jira/browse/CASSANDRA-4443 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 1.2 Reporter: Brandon Williams Fix For: 1.2 As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to split up the contiguous ranges. In addition, we still need a 'balance' utility similar to move without a token, in the cases where entropy is not your friend and gives you an unbalanced cluster (I've seen up to a 7% discrepancy myself) -- 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-4443) balance/shuffle utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4443: Issue Type: Sub-task (was: New Feature) Parent: CASSANDRA-4119 balance/shuffle utility for vnodes -- Key: CASSANDRA-4443 URL: https://issues.apache.org/jira/browse/CASSANDRA-4443 Project: Cassandra Issue Type: Sub-task Components: Core Affects Versions: 1.2 Reporter: Brandon Williams Fix For: 1.2 As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to split up the contiguous ranges. In addition, we still need a 'balance' utility similar to move without a token, in the cases where entropy is not your friend and gives you an unbalanced cluster (I've seen up to a 7% discrepancy myself) -- 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-4125) Update nodetool for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417280#comment-13417280
]
Eric Evans commented on CASSANDRA-4125:
---
The ownership calculation should be fixed now.
Update nodetool for vnodes
--
Key: CASSANDRA-4125
URL: https://issues.apache.org/jira/browse/CASSANDRA-4125
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Sam Overton
Assignee: Eric Evans
The proposed changes are intended to preserve backwards compatibility:
|| op || behaviour || deprecated warning?
| join | Join the ring, use with {{-t}} to join at a specific token, or to
add a token to an existing host |
| ring | prints the first token for each node, add {{-a}} to print all tokens
|
| move new token | if the node only has 1 token then move it. Otherwise die
with an error. | *deprecated*
| removetoken status/force/token | removes the node who owns token from
the ring. use {{-t}} option to only remove the token from the node instead of
the whole node. |
| describering [keyspace] | show all ranges and their endpoints |
| getendpoints keyspace cf key | Print the endpoints that own the key
and also their list of tokens |
_Edit0: Appended patch information._
h3. Patches
||Compare||Raw diff||Description||
|[01_admin_tools|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools]|[01_admin_tools.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools.diff]|Updated
nodetool|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4127) migration support for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417285#comment-13417285
]
Brandon Williams commented on CASSANDRA-4127:
-
bq. Since we already have vnode migration for bootstrap / decommission,
couldn't we just add a nodetool shuffle command to do that in-place instead?
Created CASSANDRA-4443 for this.
+1
migration support for vnodes
Key: CASSANDRA-4127
URL: https://issues.apache.org/jira/browse/CASSANDRA-4127
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Sam Overton
Assignee: Sam Overton
Labels: vnodes
If, when starting up for the first time, the host only has 1 token but
num_tokens is configured differently, then this will trigger a migration
process:
* The host will assign itself num_tokens tokens in its own range
* The new tokens will be gossiped
This will allow a rolling migration where N new hosts are bootstrapped into
the cluster (with num_tokens set appropriately) and then the N old nodes are
decommissioned. This will result in even distribution of the data among the
new nodes with randomly assigned tokens.
_Edit0: Appended patch information._
h3. Patches
||Compare||Raw diff||Description||
|[01_migration_path|https://github.com/acunu/cassandra/compare/top-bases/p/4127/01_migration_path...p/4127/01_migration_path]|[01_migration_path.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4127/01_migration_path...p/4127/01_migration_path.diff]|Migrate
from one token to many|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4125) Update nodetool for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417287#comment-13417287
]
Brandon Williams commented on CASSANDRA-4125:
-
+1
Update nodetool for vnodes
--
Key: CASSANDRA-4125
URL: https://issues.apache.org/jira/browse/CASSANDRA-4125
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Sam Overton
Assignee: Eric Evans
The proposed changes are intended to preserve backwards compatibility:
|| op || behaviour || deprecated warning?
| join | Join the ring, use with {{-t}} to join at a specific token, or to
add a token to an existing host |
| ring | prints the first token for each node, add {{-a}} to print all tokens
|
| move new token | if the node only has 1 token then move it. Otherwise die
with an error. | *deprecated*
| removetoken status/force/token | removes the node who owns token from
the ring. use {{-t}} option to only remove the token from the node instead of
the whole node. |
| describering [keyspace] | show all ranges and their endpoints |
| getendpoints keyspace cf key | Print the endpoints that own the key
and also their list of tokens |
_Edit0: Appended patch information._
h3. Patches
||Compare||Raw diff||Description||
|[01_admin_tools|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools]|[01_admin_tools.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools.diff]|Updated
nodetool|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4122) Bootstrap and decommission with multiple ranges for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417289#comment-13417289
]
Brandon Williams commented on CASSANDRA-4122:
-
+1
Bootstrap and decommission with multiple ranges for vnodes
--
Key: CASSANDRA-4122
URL: https://issues.apache.org/jira/browse/CASSANDRA-4122
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Sam Overton
Assignee: Sam Overton
Bootstrap:
* New config parameter num_tokens which is used iff initial_token is not set.
* Both initial_token and replace_token will allow a comma-separated list of
tokens so multiple tokens can be configured explicitly if required.
* Bootstrapper.getBalancedToken will be deprecated and used only in the case
that num_tokens == 1. Instead, if initial token is not specified, num_tokens
tokens will be randomly chosen.
* The existing logic can be used to calculate the new ranges which must be
streamed.
Decommission:
* The existing logic can be used with some minor modifications to account for
multiple tokens per host
_Edit0: appended patch information._
_Edit1: added 03_group_stream_out_ranges patch._
h3. Patches
||Compare||Raw diff||Description||
|[01_bootstrap_decommission|https://github.com/acunu/cassandra/compare/top-bases/p/4122/01_bootstrap_decommission...p/4122/01_bootstrap_decommission]|[01_bootstrap_decommission.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4122/01_bootstrap_decommission...p/4122/01_bootstrap_decommission.diff]|No
Description|
|[02_remove_tokens|https://github.com/acunu/cassandra/compare/top-bases/p/4122/02_remove_tokens...p/4122/02_remove_tokens]|[02_remove_tokens.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4122/02_remove_tokens...p/4122/02_remove_tokens.diff]|No
Description|
|[03_group_stream_out_ranges|https://github.com/acunu/cassandra/compare/top-bases/p/4122/03_group_stream_out_ranges...p/4122/03_group_stream_out_ranges]|[03_group_stream_out_ranges.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4122/03_group_stream_out_ranges...p/4122/03_group_stream_out_ranges.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4240) Only check the size of indexed column values when they are of type KEYS
[ https://issues.apache.org/jira/browse/CASSANDRA-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-4240: Attachment: cassandra-1.0.8-CASSANDRA-4240-patch4.txt Only check the size of indexed column values when they are of type KEYS --- Key: CASSANDRA-4240 URL: https://issues.apache.org/jira/browse/CASSANDRA-4240 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.0 Reporter: Joaquin Casares Priority: Minor Labels: datastax_qa Attachments: CASSANDRA-4240.patch, CASSANDRA-4240.patch1, cassandra-1.0.8-CASSANDRA-4240-patch2.txt, cassandra-1.0.8-CASSANDRA-4240-patch3.txt, cassandra-1.0.8-CASSANDRA-4240-patch4.txt, cassandra-1.0.8-CASSANDRA-4240.txt https://github.com/apache/cassandra/blob/cassandra-1.0.8/src/java/org/apache/cassandra/thrift/ThriftValidation.java#L431 That line states that: Indexed column values cannot be larger than 64K. But in some cases we would want the column values to be able to be larger than 64k, specifically if the index_type is not of type KEYS. -- 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-4436) Counters in columns don't preserve correct values after cluster restart
[ https://issues.apache.org/jira/browse/CASSANDRA-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4436: Attachment: 4436-1.1.txt 4436-1.0.txt Thanks a lot Peter for helping out reproducing this issue. The problem is that when a node stops (or is drained for that matter, we don't wait for all compaction to end during drain as this could mean waiting for a very long time, at least with SizeTieredCompaction) just when a compaction is finishing, it is possible for some of the compacted file to not have -Compacted components even if the compacted file is not temporary anymore. In other words, it is possible that when the node is restart, it will load both the compacted files and some of the file used to compact it. While this is harmless (though inefficient) for normal column family, this means overcounting for counters. I'll note that even though I can't reproduce the counter bug on 1.1 with the test case above, it is just luck as 1.1 is affected as well. What we need to guarantee is that we will never use both a compacted file and one of it's ancestor. One way to ensure that is to keep in the metadata of the compacted file, the list of it's ancestors (we only need to keep the generation). Then when a node start, it can gather all the ancestors of all the sstable in the data dir, and delete all those sstable that are in this ancestor set. Since we don't want to keep ever going list of ancestors however, a newly compacted sstable only need to keep the list of it's still live ancestor (which 99% of the time means keeping only the generation of the file that were compacted to obtain it). I note that if we do that, we don't need to generate -Compacted components. Attaching patch to implement this. Attaching a patch for 1.0 and 1.1 (which aren't very different). I wrote the 1.0 version because it's on this version that I knew how to reproduce the counter bug reliably, and I've checked that this patch does fix the issue. However, this patch doesn't only affect counter code and is not trivial per se, so I don't know how I feel about risking to breaking things on 1.0 for non-counter user at this point. I think it might me wiser to put this in 1.1.3 only and say that counter users should either apply the attached patch at their own risk or upgrade to 1.1.3. Counters in columns don't preserve correct values after cluster restart --- Key: CASSANDRA-4436 URL: https://issues.apache.org/jira/browse/CASSANDRA-4436 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.10 Reporter: Peter Velas Assignee: Sylvain Lebresne Fix For: 1.1.3 Attachments: 4436-1.0.txt, 4436-1.1.txt, increments.cql.gz Similar to #3821. but affecting normal columns. Set up a 2-node cluster with rf=2. 1. Create a counter column family and increment a 100 keys in loop 5000 times. 2. Then make a rolling restart to cluster. 3. Again increment another 5000 times. 4. Make a rolling restart to cluster. 5. Again increment another 5000 times. 6. Make a rolling restart to cluster. After step 6 we were able to reproduce bug with bad counter values. Expected values were 15 000. Values returned from cluster are higher then 15000 + some random number. Rolling restarts are done with nodetool drain. Always waiting until second node discover its down then kill java process. -- 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
[3/5] git commit: group stream out ranges
group stream out ranges
Patch by Sam Overton; reviewed by Brandon Williams for CASSANDRA-4122
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8c09e87e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8c09e87e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8c09e87e
Branch: refs/heads/trunk
Commit: 8c09e87e40020139611088cf836f8f079bffb0ce
Parents: 1a3661f
Author: Eric Evans eev...@apache.org
Authored: Wed Jul 18 13:35:53 2012 -0500
Committer: Eric Evans eev...@apache.org
Committed: Wed Jul 18 13:35:53 2012 -0500
--
.../apache/cassandra/service/StorageService.java | 51 ++
1 files changed, 36 insertions(+), 15 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8c09e87e/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 207bf69..3875054 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -2984,42 +2984,62 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
*/
private CountDownLatch streamRanges(final MapString,
MultimapRangeToken, InetAddress rangesToStreamByTable)
{
-final CountDownLatch latch = new
CountDownLatch(rangesToStreamByTable.keySet().size());
+// First, we build a list of ranges to stream to each host, per table
+final MapString, MapInetAddress, ListRangeToken
sessionsToStreamByTable = new HashMapString, MapInetAddress,
ListRangeToken();
+// The number of stream out sessions we need to start, to be built up
as we build sessionsToStreamByTable
+int sessionCount = 0;
+
for (Map.EntryString, MultimapRangeToken, InetAddress entry :
rangesToStreamByTable.entrySet())
{
MultimapRangeToken, InetAddress rangesWithEndpoints =
entry.getValue();
if (rangesWithEndpoints.isEmpty())
-{
-latch.countDown();
continue;
-}
final String table = entry.getKey();
-final SetMap.EntryRangeToken, InetAddress pending = new
HashSetMap.EntryRangeToken, InetAddress(rangesWithEndpoints.entries());
+MapInetAddress, ListRangeToken rangesPerEndpoint = new
HashMapInetAddress, ListRangeToken();
for (final Map.EntryRangeToken, InetAddress endPointEntry :
rangesWithEndpoints.entries())
{
final RangeToken range = endPointEntry.getKey();
-final InetAddress newEndpoint = endPointEntry.getValue();
+final InetAddress endpoint = endPointEntry.getValue();
+
+ListRangeToken curRanges = rangesPerEndpoint.get(endpoint);
+if (curRanges == null)
+{
+curRanges = new LinkedListRangeToken();
+rangesPerEndpoint.put(endpoint, curRanges);
+}
+curRanges.add(range);
+}
+
+sessionCount += rangesPerEndpoint.size();
+sessionsToStreamByTable.put(table, rangesPerEndpoint);
+}
+
+final CountDownLatch latch = new CountDownLatch(sessionCount);
+
+for (Map.EntryString, MapInetAddress, ListRangeToken entry :
sessionsToStreamByTable.entrySet())
+{
+final String table = entry.getKey();
+final MapInetAddress, ListRangeToken rangesPerEndpoint =
entry.getValue();
+
+for (final Map.EntryInetAddress, ListRangeToken rangesEntry
: rangesPerEndpoint.entrySet())
+{
+final ListRangeToken ranges = rangesEntry.getValue();
+final InetAddress newEndpoint = rangesEntry.getKey();
final IStreamCallback callback = new IStreamCallback()
{
public void onSuccess()
{
-synchronized (pending)
-{
-pending.remove(endPointEntry);
-
-if (pending.isEmpty())
-latch.countDown();
-}
+latch.countDown();
}
public void onFailure()
{
-logger.warn(Streaming to + endPointEntry +
failed);
+logger.warn(Streaming to + newEndpoint + failed);
onSuccess(); // calling onSuccess for latch countdown
}
};
@@ -3029,7 +3049,8 @@
[2/5] git commit: jmx / nodetool support for virtual nodes
jmx / nodetool support for virtual nodes
Patch by eevans; reviewed by Brandon Williams for CASSANDRA-4125
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4f9fd76d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4f9fd76d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4f9fd76d
Branch: refs/heads/trunk
Commit: 4f9fd76db3b63cea98426097e424524dc07237ad
Parents: 8c09e87
Author: Eric Evans eev...@apache.org
Authored: Wed Jul 18 13:39:29 2012 -0500
Committer: Eric Evans eev...@apache.org
Committed: Wed Jul 18 13:39:29 2012 -0500
--
.../apache/cassandra/service/StorageService.java | 54 ++--
.../cassandra/service/StorageServiceMBean.java | 14 +-
src/java/org/apache/cassandra/tools/NodeCmd.java | 282 ---
src/java/org/apache/cassandra/tools/NodeProbe.java | 18 +-
4 files changed, 283 insertions(+), 85 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4f9fd76d/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 3875054..b5d6d20 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -1726,9 +1726,22 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
/* These methods belong to the MBean interface */
-public String getToken()
+public ListString getTokens()
{
-return getLocalTokens().iterator().next().toString();
+return getTokens(FBUtilities.getBroadcastAddress());
+}
+
+public ListString getTokens(String endpoint) throws UnknownHostException
+{
+return getTokens(InetAddress.getByName(endpoint));
+}
+
+private ListString getTokens(InetAddress endpoint)
+{
+ListString strTokens = new ArrayListString();
+for (Token tok : getTokenMetadata().getTokens(endpoint))
+strTokens.add(tok.toString());
+return strTokens;
}
public String getReleaseVersion()
@@ -2432,6 +2445,14 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
// address of the current node
InetAddress localAddress = FBUtilities.getBroadcastAddress();
+
+// This doesn't make any sense in a vnodes environment.
+if (getTokenMetadata().getTokens(localAddress).size() 1)
+{
+logger.error(Invalid request to move(Token); This node has more
than one token and cannot be moved thusly.);
+throw new UnsupportedOperationException(This node has more than
one token and cannot be moved thusly.);
+}
+
ListString tablesToProcess = Schema.instance.getNonSystemTables();
// checking if data is moving to this node
@@ -2861,39 +2882,14 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
// calculate ownership per dc
for (CollectionInetAddress endpoints : endpointsGroupedByDc)
{
-// sort the endpoints by their tokens
-ListInetAddress sortedEndpoints =
Lists.newArrayListWithExpectedSize(endpoints.size());
-sortedEndpoints.addAll(endpoints);
-
-Collections.sort(sortedEndpoints, new ComparatorInetAddress()
-{
-public int compare(InetAddress o1, InetAddress o2)
-{
-byte[] b1 = o1.getAddress();
-byte[] b2 = o2.getAddress();
-
-if(b1.length b2.length) return -1;
-if(b1.length b2.length) return 1;
-
-for(int i = 0; i b1.length; i++)
-{
-int left = (int)b1[i] 0xFF;
-int right = (int)b2[i] 0xFF;
-if (left right) return -1;
-else if (left right) return 1;
-}
-return 0;
-}
-});
-
// calculate the ownership with replication and add the endpoint
to the final ownership map
for (InetAddress endpoint : endpoints)
{
float ownership = 0.0f;
for (RangeToken range : getRangesForEndpoint(keyspace,
endpoint))
{
-if (tokenOwnership.containsKey(range.left))
-ownership += tokenOwnership.get(range.left);
+if (tokenOwnership.containsKey(range.right))
+ownership += tokenOwnership.get(range.right);
}
[4/5] git commit: support for node removal with virtual nodes
support for node removal with virtual nodes
Patch by Sam Overton and eevans; reviewed by Brandon Williams for CASSANDRA-4122
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1a3661f6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1a3661f6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1a3661f6
Branch: refs/heads/trunk
Commit: 1a3661f641e62d3fdc03eae32c60b2b33a5d90bb
Parents: 66b96ee
Author: Eric Evans eev...@apache.org
Authored: Wed Jul 18 13:34:02 2012 -0500
Committer: Eric Evans eev...@apache.org
Committed: Wed Jul 18 13:34:02 2012 -0500
--
.../apache/cassandra/service/StorageService.java | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1a3661f6/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index a58653d..207bf69 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -1305,18 +1305,16 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
if (tokenMetadata.isMember(endpoint))
{
String state = pieces[0];
-Token removeToken = tokenMetadata.getToken(endpoint);
+CollectionToken removeTokens = tokenMetadata.getTokens(endpoint);
if (VersionedValue.REMOVED_TOKEN.equals(state))
{
-excise(Collections.singleton(removeToken),
- endpoint,
- extractExpireTime(pieces,
MessagingService.instance().getVersion(endpoint)));
+excise(removeTokens, endpoint, extractExpireTime(pieces,
MessagingService.instance().getVersion(endpoint)));
}
else if (VersionedValue.REMOVING_TOKEN.equals(state))
{
if (logger.isDebugEnabled())
-logger.debug(Token + removeToken + removed manually
(endpoint was + endpoint + ));
+logger.debug(Tokens + removeTokens + removed manually
(endpoint was + endpoint + ));
// Note that the endpoint is being removed
tokenMetadata.addLeavingEndpoint(endpoint);
@@ -2580,8 +2578,7 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
{
UUID hostId = tokenMetadata.getHostId(endpoint);
Gossiper.instance.advertiseTokenRemoved(endpoint, hostId);
-Token token = tokenMetadata.getToken(endpoint);
-excise(Collections.singleton(token), endpoint);
+excise(tokenMetadata.getTokens(endpoint), endpoint);
}
replicatingNodes.clear();
removingNode = null;
@@ -2611,7 +2608,7 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
if (endpoint == null)
throw new UnsupportedOperationException(Host ID not found.);
-Token token = tokenMetadata.getToken(endpoint);
+CollectionToken tokens = tokenMetadata.getTokens(endpoint);
if (endpoint.equals(myAddress))
throw new UnsupportedOperationException(Cannot remove self);
@@ -2669,7 +2666,7 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
}
}
-excise(Collections.singleton(token), endpoint);
+excise(tokens, endpoint);
// gossiper will indicate the token has left
Gossiper.instance.advertiseTokenRemoved(endpoint, hostId);
[1/5] git commit: migration support for virtual nodes
Updated Branches:
refs/heads/trunk 72aa82401 - 201fe9441
migration support for virtual nodes
Patch by Sam Overton; reviewed by Brandon Williams for CASSANDRA-4127
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/201fe944
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/201fe944
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/201fe944
Branch: refs/heads/trunk
Commit: 201fe94413db0125d73e01afff45fa6bd7b295a0
Parents: 4f9fd76
Author: Eric Evans eev...@apache.org
Authored: Wed Jul 18 13:47:39 2012 -0500
Committer: Eric Evans eev...@apache.org
Committed: Wed Jul 18 13:47:39 2012 -0500
--
.../apache/cassandra/service/StorageService.java | 53 ++-
1 files changed, 52 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/201fe944/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index b5d6d20..621b06b 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -621,7 +621,58 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
}
else
{
-logger.info(Using saved token + tokens);
+// if we were already bootstrapped with 1 token but num_tokens
is set higher in the config,
+// then we need to migrate to multi-token
+if (tokens.size() == 1 DatabaseDescriptor.getNumTokens()
1)
+{
+// wait for ring info
+logger.info(Sleeping for ring delay ( + delay + ms));
+try
+{
+Thread.sleep(delay);
+}
+catch (InterruptedException e)
+{
+throw new AssertionError(e);
+}
+logger.info(Calculating new tokens);
+// calculate num_tokens tokens evenly spaced in the range
(left, right]
+Token right = tokens.iterator().next();
+TokenMetadata clone = tokenMetadata.cloneOnlyTokenMap();
+clone.updateNormalToken(right,
FBUtilities.getBroadcastAddress());
+Token left = clone.getPredecessor(right);
+
+// get (num_tokens - 1) tokens spaced evenly, and the last
token will be our current token (right)
+for (int tok = 1; tok DatabaseDescriptor.getNumTokens();
++tok)
+{
+Token l = left;
+Token r = right;
+// iteratively calculate the location of the token
using midpoint
+// num iterations is number of bits in IEE754 mantissa
(including implicit leading 1)
+// we stop early for terminating fractions
+// TODO: alternatively we could add an interpolate()
method to IPartitioner
+double frac = (double)tok /
(double)DatabaseDescriptor.getNumTokens();
+Token midpoint = getPartitioner().midpoint(l, r);
+for (int i = 0; i 53; ++i)
+{
+frac *= 2;
+if (frac == 1.0) /* not a bug */
+break;
+else if (frac 1.0)
+{
+l = midpoint;
+frac -= 1.0;
+}
+else
+r = midpoint;
+midpoint = getPartitioner().midpoint(l, r);
+}
+tokens.add(midpoint);
+}
+logger.info(Split previous range ( + left + , + right
+ ] into + tokens);
+}
+else
+logger.info(Using saved token + tokens);
}
}
[1/10] git commit: Merge branch 'p/4122/03_group_stream_out_ranges' into refs/top-bases/p/4125/01_admin_tools
Updated Branches: refs/heads/vnodes 4352f7936 - 59858123d Merge branch 'p/4122/03_group_stream_out_ranges' into refs/top-bases/p/4125/01_admin_tools Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/35d5c2f5 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/35d5c2f5 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/35d5c2f5 Branch: refs/heads/vnodes Commit: 35d5c2f55067ee5dc40684b8362d94b44f8a033c Parents: 0ed12b7 3d0b6e1 Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 13:22:48 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 13:22:48 2012 -0500 -- --
[3/10] git commit: Merge commit 'refs/top-bases/p/4127/01_migration_path' into p/4127/01_migration_path
Merge commit 'refs/top-bases/p/4127/01_migration_path' into p/4127/01_migration_path Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/59858123 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/59858123 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/59858123 Branch: refs/heads/vnodes Commit: 59858123df4b21075d2f97b22543de597d871245 Parents: 4352f79 383bd7d Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 13:22:48 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 13:22:48 2012 -0500 -- --
[9/10] git commit: remove dependency on trunk
remove dependency on trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/cfa2f467 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cfa2f467 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cfa2f467 Branch: refs/heads/vnodes Commit: cfa2f4673675c6c1a0449c27bff71f3c4e3c71bd Parents: af7cd1c Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 13:20:37 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 13:20:37 2012 -0500 -- .topdeps |1 - 1 files changed, 0 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/cfa2f467/.topdeps -- diff --git a/.topdeps b/.topdeps index 7b5c730..6b1d812 100644 --- a/.topdeps +++ b/.topdeps @@ -1,2 +1 @@ -trunk trunk/4122-4127
[10/10] git commit: New TopGit dependency: trunk/4122-4127
New TopGit dependency: trunk/4122-4127 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/af7cd1c3 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/af7cd1c3 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/af7cd1c3 Branch: refs/heads/vnodes Commit: af7cd1c37f2caee3410a03c2cae27d05d6abaeed Parents: e4ff7dd Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 13:20:23 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 13:20:23 2012 -0500 -- .topdeps |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/af7cd1c3/.topdeps -- diff --git a/.topdeps b/.topdeps index b5d9bfd..7b5c730 100644 --- a/.topdeps +++ b/.topdeps @@ -1 +1,2 @@ trunk +trunk/4122-4127
[4/10] git commit: Merge commit 'refs/top-bases/p/4125/01_admin_tools' into p/4125/01_admin_tools
Merge commit 'refs/top-bases/p/4125/01_admin_tools' into p/4125/01_admin_tools Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7b3604a8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7b3604a8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7b3604a8 Branch: refs/heads/vnodes Commit: 7b3604a889c6d8a9a6dfb5120be050b72ecc618e Parents: 606adeb 35d5c2f Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 13:22:48 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 13:22:48 2012 -0500 -- --
[8/10] git commit: Merge commit 'refs/top-bases/p/4122/02_remove_tokens' into p/4122/02_remove_tokens
Merge commit 'refs/top-bases/p/4122/02_remove_tokens' into p/4122/02_remove_tokens Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f3eadb58 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f3eadb58 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f3eadb58 Branch: refs/heads/vnodes Commit: f3eadb5874a29f70b4e9b76777dcc4f657b05e7c Parents: b4b6a57 422a775 Author: Eric Evans eev...@apache.org Authored: Wed Jul 18 13:20:53 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Wed Jul 18 13:20:53 2012 -0500 -- --
[jira] [Resolved] (CASSANDRA-4122) Bootstrap and decommission with multiple ranges for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans resolved CASSANDRA-4122.
---
Resolution: Fixed
committed to trunk; thanks everyone!
Bootstrap and decommission with multiple ranges for vnodes
--
Key: CASSANDRA-4122
URL: https://issues.apache.org/jira/browse/CASSANDRA-4122
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Sam Overton
Assignee: Sam Overton
Bootstrap:
* New config parameter num_tokens which is used iff initial_token is not set.
* Both initial_token and replace_token will allow a comma-separated list of
tokens so multiple tokens can be configured explicitly if required.
* Bootstrapper.getBalancedToken will be deprecated and used only in the case
that num_tokens == 1. Instead, if initial token is not specified, num_tokens
tokens will be randomly chosen.
* The existing logic can be used to calculate the new ranges which must be
streamed.
Decommission:
* The existing logic can be used with some minor modifications to account for
multiple tokens per host
_Edit0: appended patch information._
_Edit1: added 03_group_stream_out_ranges patch._
h3. Patches
||Compare||Raw diff||Description||
|[01_bootstrap_decommission|https://github.com/acunu/cassandra/compare/top-bases/p/4122/01_bootstrap_decommission...p/4122/01_bootstrap_decommission]|[01_bootstrap_decommission.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4122/01_bootstrap_decommission...p/4122/01_bootstrap_decommission.diff]|No
Description|
|[02_remove_tokens|https://github.com/acunu/cassandra/compare/top-bases/p/4122/02_remove_tokens...p/4122/02_remove_tokens]|[02_remove_tokens.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4122/02_remove_tokens...p/4122/02_remove_tokens.diff]|No
Description|
|[03_group_stream_out_ranges|https://github.com/acunu/cassandra/compare/top-bases/p/4122/03_group_stream_out_ranges...p/4122/03_group_stream_out_ranges]|[03_group_stream_out_ranges.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4122/03_group_stream_out_ranges...p/4122/03_group_stream_out_ranges.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4125) Update nodetool for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-4125:
--
Fix Version/s: 1.2
Update nodetool for vnodes
--
Key: CASSANDRA-4125
URL: https://issues.apache.org/jira/browse/CASSANDRA-4125
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Sam Overton
Assignee: Eric Evans
Fix For: 1.2
The proposed changes are intended to preserve backwards compatibility:
|| op || behaviour || deprecated warning?
| join | Join the ring, use with {{-t}} to join at a specific token, or to
add a token to an existing host |
| ring | prints the first token for each node, add {{-a}} to print all tokens
|
| move new token | if the node only has 1 token then move it. Otherwise die
with an error. | *deprecated*
| removetoken status/force/token | removes the node who owns token from
the ring. use {{-t}} option to only remove the token from the node instead of
the whole node. |
| describering [keyspace] | show all ranges and their endpoints |
| getendpoints keyspace cf key | Print the endpoints that own the key
and also their list of tokens |
_Edit0: Appended patch information._
h3. Patches
||Compare||Raw diff||Description||
|[01_admin_tools|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools]|[01_admin_tools.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools.diff]|Updated
nodetool|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4122) Bootstrap and decommission with multiple ranges for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-4122:
--
Fix Version/s: 1.2
Bootstrap and decommission with multiple ranges for vnodes
--
Key: CASSANDRA-4122
URL: https://issues.apache.org/jira/browse/CASSANDRA-4122
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Sam Overton
Assignee: Sam Overton
Fix For: 1.2
Bootstrap:
* New config parameter num_tokens which is used iff initial_token is not set.
* Both initial_token and replace_token will allow a comma-separated list of
tokens so multiple tokens can be configured explicitly if required.
* Bootstrapper.getBalancedToken will be deprecated and used only in the case
that num_tokens == 1. Instead, if initial token is not specified, num_tokens
tokens will be randomly chosen.
* The existing logic can be used to calculate the new ranges which must be
streamed.
Decommission:
* The existing logic can be used with some minor modifications to account for
multiple tokens per host
_Edit0: appended patch information._
_Edit1: added 03_group_stream_out_ranges patch._
h3. Patches
||Compare||Raw diff||Description||
|[01_bootstrap_decommission|https://github.com/acunu/cassandra/compare/top-bases/p/4122/01_bootstrap_decommission...p/4122/01_bootstrap_decommission]|[01_bootstrap_decommission.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4122/01_bootstrap_decommission...p/4122/01_bootstrap_decommission.diff]|No
Description|
|[02_remove_tokens|https://github.com/acunu/cassandra/compare/top-bases/p/4122/02_remove_tokens...p/4122/02_remove_tokens]|[02_remove_tokens.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4122/02_remove_tokens...p/4122/02_remove_tokens.diff]|No
Description|
|[03_group_stream_out_ranges|https://github.com/acunu/cassandra/compare/top-bases/p/4122/03_group_stream_out_ranges...p/4122/03_group_stream_out_ranges]|[03_group_stream_out_ranges.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4122/03_group_stream_out_ranges...p/4122/03_group_stream_out_ranges.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4125) Update nodetool for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans resolved CASSANDRA-4125.
---
Resolution: Fixed
committed to trunk; thanks everyone!
Update nodetool for vnodes
--
Key: CASSANDRA-4125
URL: https://issues.apache.org/jira/browse/CASSANDRA-4125
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Sam Overton
Assignee: Eric Evans
Fix For: 1.2
The proposed changes are intended to preserve backwards compatibility:
|| op || behaviour || deprecated warning?
| join | Join the ring, use with {{-t}} to join at a specific token, or to
add a token to an existing host |
| ring | prints the first token for each node, add {{-a}} to print all tokens
|
| move new token | if the node only has 1 token then move it. Otherwise die
with an error. | *deprecated*
| removetoken status/force/token | removes the node who owns token from
the ring. use {{-t}} option to only remove the token from the node instead of
the whole node. |
| describering [keyspace] | show all ranges and their endpoints |
| getendpoints keyspace cf key | Print the endpoints that own the key
and also their list of tokens |
_Edit0: Appended patch information._
h3. Patches
||Compare||Raw diff||Description||
|[01_admin_tools|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools]|[01_admin_tools.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4125/01_admin_tools...p/4125/01_admin_tools.diff]|Updated
nodetool|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4127) migration support for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-4127:
--
Fix Version/s: 1.2
migration support for vnodes
Key: CASSANDRA-4127
URL: https://issues.apache.org/jira/browse/CASSANDRA-4127
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Sam Overton
Assignee: Sam Overton
Labels: vnodes
Fix For: 1.2
If, when starting up for the first time, the host only has 1 token but
num_tokens is configured differently, then this will trigger a migration
process:
* The host will assign itself num_tokens tokens in its own range
* The new tokens will be gossiped
This will allow a rolling migration where N new hosts are bootstrapped into
the cluster (with num_tokens set appropriately) and then the N old nodes are
decommissioned. This will result in even distribution of the data among the
new nodes with randomly assigned tokens.
_Edit0: Appended patch information._
h3. Patches
||Compare||Raw diff||Description||
|[01_migration_path|https://github.com/acunu/cassandra/compare/top-bases/p/4127/01_migration_path...p/4127/01_migration_path]|[01_migration_path.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4127/01_migration_path...p/4127/01_migration_path.diff]|Migrate
from one token to many|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4127) migration support for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans resolved CASSANDRA-4127.
---
Resolution: Fixed
committed to trunk; thanks everyone!
migration support for vnodes
Key: CASSANDRA-4127
URL: https://issues.apache.org/jira/browse/CASSANDRA-4127
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Sam Overton
Assignee: Sam Overton
Labels: vnodes
Fix For: 1.2
If, when starting up for the first time, the host only has 1 token but
num_tokens is configured differently, then this will trigger a migration
process:
* The host will assign itself num_tokens tokens in its own range
* The new tokens will be gossiped
This will allow a rolling migration where N new hosts are bootstrapped into
the cluster (with num_tokens set appropriately) and then the N old nodes are
decommissioned. This will result in even distribution of the data among the
new nodes with randomly assigned tokens.
_Edit0: Appended patch information._
h3. Patches
||Compare||Raw diff||Description||
|[01_migration_path|https://github.com/acunu/cassandra/compare/top-bases/p/4127/01_migration_path...p/4127/01_migration_path]|[01_migration_path.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4127/01_migration_path...p/4127/01_migration_path.diff]|Migrate
from one token to many|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-3647) Support set and map value types in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3647:
---
Attachment: CASSANDRA-3647-alternative.patch
Reopening this because it because committed code doesn't work and attaching my
alternative version with changes I was taking about in my previous comments.
When I try to do SET operation on any collection type I get following
exception:
{noformat}
java.lang.IllegalStateException: Composite column is already fully constructed
at
org.apache.cassandra.db.marshal.CompositeType$Builder.buildAsEndOfRange(CompositeType.java:290)
at
org.apache.cassandra.cql3.statements.UpdateStatement.addToMutation(UpdateStatement.java:250)
at
org.apache.cassandra.cql3.statements.UpdateStatement.mutationForKey(UpdateStatement.java:218)
at
org.apache.cassandra.cql3.statements.UpdateStatement.getMutations(UpdateStatement.java:171)
at
org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:84)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:116)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1240)
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:184)
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)
{noformat}
Following exceptions observed on List.Append:
{noformat}
java.lang.IllegalStateException: Composite column is already fully constructed
at
org.apache.cassandra.db.marshal.CompositeType$Builder.add(CompositeType.java:264)
at
org.apache.cassandra.db.marshal.CompositeType$Builder.add(CompositeType.java:196)
at
org.apache.cassandra.db.marshal.ListType.doAppend(ListType.java:197)
at
org.apache.cassandra.db.marshal.ListType.executeFunction(ListType.java:128)
at
org.apache.cassandra.db.marshal.CollectionType.execute(CollectionType.java:84)
at
org.apache.cassandra.cql3.statements.UpdateStatement.addToMutation(UpdateStatement.java:286)
at
org.apache.cassandra.cql3.statements.UpdateStatement.mutationForKey(UpdateStatement.java:218)
at
org.apache.cassandra.cql3.statements.UpdateStatement.getMutations(UpdateStatement.java:171)
at
org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:84)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:116)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1240)
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:184)
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)
{noformat}
And Set.Add
{noformat}
ava.lang.IllegalStateException: Composite column is already fully constructed
at
org.apache.cassandra.db.marshal.CompositeType$Builder.add(CompositeType.java:264)
at
org.apache.cassandra.db.marshal.CompositeType$Builder.add(CompositeType.java:196)
at org.apache.cassandra.db.marshal.SetType.doAdd(SetType.java:111)
at
org.apache.cassandra.db.marshal.SetType.executeFunction(SetType.java:96)
at
org.apache.cassandra.db.marshal.CollectionType.execute(CollectionType.java:84)
at
org.apache.cassandra.cql3.statements.UpdateStatement.addToMutation(UpdateStatement.java:286)
at
[jira] [Reopened] (CASSANDRA-3647) Support set and map value types in CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich reopened CASSANDRA-3647: Support set and map value types in CQL -- Key: CASSANDRA-3647 URL: https://issues.apache.org/jira/browse/CASSANDRA-3647 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Labels: cql Fix For: 1.2 Attachments: CASSANDRA-3647-alternative.patch Composite columns introduce the ability to have arbitrarily nested data in a Cassandra row. We should expose this through CQL. -- 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-4240) Only check the size of indexed column values when they are of type KEYS
[ https://issues.apache.org/jira/browse/CASSANDRA-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417646#comment-13417646 ] Jeremy Hanna commented on CASSANDRA-4240: - I tested patch 4 on a three node cluster that was using DSE's alternate secondary index implementation that allows for larger values for indexed column values. Worked fine. Jake would you mind reviewing the later patch? Only check the size of indexed column values when they are of type KEYS --- Key: CASSANDRA-4240 URL: https://issues.apache.org/jira/browse/CASSANDRA-4240 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.0 Reporter: Joaquin Casares Priority: Minor Labels: datastax_qa Attachments: CASSANDRA-4240.patch, CASSANDRA-4240.patch1, cassandra-1.0.8-CASSANDRA-4240-patch2.txt, cassandra-1.0.8-CASSANDRA-4240-patch3.txt, cassandra-1.0.8-CASSANDRA-4240-patch4.txt, cassandra-1.0.8-CASSANDRA-4240.txt https://github.com/apache/cassandra/blob/cassandra-1.0.8/src/java/org/apache/cassandra/thrift/ThriftValidation.java#L431 That line states that: Indexed column values cannot be larger than 64K. But in some cases we would want the column values to be able to be larger than 64k, specifically if the index_type is not of type KEYS. -- 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-4444) Failure to delete column families
David B created CASSANDRA-:
--
Summary: Failure to delete column families
Key: CASSANDRA-
URL: https://issues.apache.org/jira/browse/CASSANDRA-
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Environment: 2 node cluster running on Ubuntu Precise
Reporter: David B
I have a two node cluster, and one keyspace defined as follows:
create keyspace SampleKeyspace with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2};
I then create a column family as follows:
create column family SampleFamily with caching = 'keys_only' and
key_validation_class = 'LongType' and compression_options = {
sstable_compression: SnappyCompressor, chunk_length_kb: 64 }
I stream SSTables through SStableLoader.
After the load is complete, compaction begins. During this time, I request a
drop of the family through cassandra-cli using drop column family
SampleFamily.
Cassandra-cli responds that schemas are in agreement. Looking on the file
system, however, the full set of data files are still found under
data/SampleFamily (in addition to the snapshot created on drop family). There
are no errors in either system or output logs.
--
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-4443) balance/shuffle utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4443: Description: As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to split up the contiguous ranges.(was: As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to split up the contiguous ranges. In addition, we still need a 'balance' utility similar to move without a token, in the cases where entropy is not your friend and gives you an unbalanced cluster (I've seen up to a 7% discrepancy myself)) balance/shuffle utility for vnodes -- Key: CASSANDRA-4443 URL: https://issues.apache.org/jira/browse/CASSANDRA-4443 Project: Cassandra Issue Type: Sub-task Components: Core Affects Versions: 1.2 Reporter: Brandon Williams Fix For: 1.2 As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to split up the contiguous ranges. -- 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-4443) shuffle utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4443: Summary: shuffle utility for vnodes (was: balance/shuffle utility for vnodes) shuffle utility for vnodes -- Key: CASSANDRA-4443 URL: https://issues.apache.org/jira/browse/CASSANDRA-4443 Project: Cassandra Issue Type: Sub-task Components: Core Affects Versions: 1.2 Reporter: Brandon Williams Fix For: 1.2 As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to split up the contiguous ranges. -- 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-4444) Failure to delete column families
[
https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-:
-
Assignee: Pavel Yaskevich
Failure to delete column families
-
Key: CASSANDRA-
URL: https://issues.apache.org/jira/browse/CASSANDRA-
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Environment: 2 node cluster running on Ubuntu Precise
Reporter: David B
Assignee: Pavel Yaskevich
I have a two node cluster, and one keyspace defined as follows:
create keyspace SampleKeyspace with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2};
I then create a column family as follows:
create column family SampleFamily with caching = 'keys_only' and
key_validation_class = 'LongType' and compression_options = {
sstable_compression: SnappyCompressor, chunk_length_kb: 64 }
I stream SSTables through SStableLoader.
After the load is complete, compaction begins. During this time, I request a
drop of the family through cassandra-cli using drop column family
SampleFamily.
Cassandra-cli responds that schemas are in agreement. Looking on the file
system, however, the full set of data files are still found under
data/SampleFamily (in addition to the snapshot created on drop family).
There are no errors in either system or output logs.
--
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-4445) balance utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4445: Issue Type: Sub-task (was: New Feature) Parent: CASSANDRA-4119 balance utility for vnodes -- Key: CASSANDRA-4445 URL: https://issues.apache.org/jira/browse/CASSANDRA-4445 Project: Cassandra Issue Type: Sub-task Components: Core Affects Versions: 1.2 Reporter: Brandon Williams Fix For: 1.2 We need a 'balance' utility similar to move without a token, in the cases where entropy is not your friend and gives you an unbalanced cluster (I've seen up to a 7% discrepancy myself) -- 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-4445) balance utility for vnodes
Brandon Williams created CASSANDRA-4445: --- Summary: balance utility for vnodes Key: CASSANDRA-4445 URL: https://issues.apache.org/jira/browse/CASSANDRA-4445 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 1.2 Reporter: Brandon Williams Fix For: 1.2 We need a 'balance' utility similar to move without a token, in the cases where entropy is not your friend and gives you an unbalanced cluster (I've seen up to a 7% discrepancy myself) -- 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-4444) Failure to delete column families
[
https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417674#comment-13417674
]
Pavel Yaskevich commented on CASSANDRA-:
So did it actually delete your CF from keyspace metadata? You can also take a
look at CASSANDRA-4221 discussion about why SSTable files still in place if you
try to delete CF while compaction is running.
Failure to delete column families
-
Key: CASSANDRA-
URL: https://issues.apache.org/jira/browse/CASSANDRA-
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Environment: 2 node cluster running on Ubuntu Precise
Reporter: David B
Assignee: Pavel Yaskevich
I have a two node cluster, and one keyspace defined as follows:
create keyspace SampleKeyspace with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2};
I then create a column family as follows:
create column family SampleFamily with caching = 'keys_only' and
key_validation_class = 'LongType' and compression_options = {
sstable_compression: SnappyCompressor, chunk_length_kb: 64 }
I stream SSTables through SStableLoader.
After the load is complete, compaction begins. During this time, I request a
drop of the family through cassandra-cli using drop column family
SampleFamily.
Cassandra-cli responds that schemas are in agreement. Looking on the file
system, however, the full set of data files are still found under
data/SampleFamily (in addition to the snapshot created on drop family).
There are no errors in either system or output logs.
--
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-4446) nodetool drain sometimes doesn't mark commitlog fully flushed
Robert Coli created CASSANDRA-4446: -- Summary: nodetool drain sometimes doesn't mark commitlog fully flushed Key: CASSANDRA-4446 URL: https://issues.apache.org/jira/browse/CASSANDRA-4446 Project: Cassandra Issue Type: New Feature Affects Versions: 1.0.10 Environment: ubuntu 10.04 64bit Linux HOSTNAME 2.6.32-345-ec2 #48-Ubuntu SMP Wed May 2 19:29:55 UTC 2012 x86_64 GNU/Linux sun JVM cassandra 1.0.10 installed from apache deb Reporter: Robert Coli I recently wiped a customer's QA cluster. I drained each node and verified that they were drained. When I restarted the nodes, I saw the commitlog replay create a memtable and then flush it. I have attached a sanitized log snippet from a representative node at the time. It appears to show the following : 1) Drain begins 2) Drain triggers flush 3) Flush triggers compaction 4) StorageService logs DRAINED message 5) compaction thread excepts 6) on restart, same CF creates a memtable 7) and then flushes it [1] The columnfamily involved in the replay in 7) is the CF for which the compaction thread excepted in 5). This seems to suggest a timing issue whereby the exception in 5) prevents the flush in 3) from marking all the segments flushed, causing them to replay after restart. [1] Isn't commitlog replay not supposed to automatically trigger a flush in modern cassandra? -- 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-3974) Per-CF TTL
[ https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Coli updated CASSANDRA-3974: --- Attachment: cassandra.1.0.10.replaying.log.after.exception.during.drain.txt Per-CF TTL -- Key: CASSANDRA-3974 URL: https://issues.apache.org/jira/browse/CASSANDRA-3974 Project: Cassandra Issue Type: New Feature Affects Versions: 1.2 Reporter: Jonathan Ellis Assignee: Kirk True Priority: Minor Fix For: 1.2 Attachments: cassandra.1.0.10.replaying.log.after.exception.during.drain.txt, trunk-3974.txt, trunk-3974v2.txt, trunk-3974v3.txt Per-CF TTL would allow compaction optimizations (drop an entire sstable's worth of expired data) that we can't do with per-column. -- 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-3974) Per-CF TTL
[ https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Coli updated CASSANDRA-3974: --- Attachment: (was: cassandra.1.0.10.replaying.log.after.exception.during.drain.txt) Per-CF TTL -- Key: CASSANDRA-3974 URL: https://issues.apache.org/jira/browse/CASSANDRA-3974 Project: Cassandra Issue Type: New Feature Affects Versions: 1.2 Reporter: Jonathan Ellis Assignee: Kirk True Priority: Minor Fix For: 1.2 Attachments: trunk-3974.txt, trunk-3974v2.txt, trunk-3974v3.txt Per-CF TTL would allow compaction optimizations (drop an entire sstable's worth of expired data) that we can't do with per-column. -- 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-3974) Per-CF TTL
[ https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417710#comment-13417710 ] Robert Coli commented on CASSANDRA-3974: Sorry for the erroneous attachment, somehow JIRA produced a link on creation of https://issues.apache.org/jira/browse/CASSANDRA-4446 which directed me here and I attached before I noticed it was the wrong ticket. Per-CF TTL -- Key: CASSANDRA-3974 URL: https://issues.apache.org/jira/browse/CASSANDRA-3974 Project: Cassandra Issue Type: New Feature Affects Versions: 1.2 Reporter: Jonathan Ellis Assignee: Kirk True Priority: Minor Fix For: 1.2 Attachments: trunk-3974.txt, trunk-3974v2.txt, trunk-3974v3.txt Per-CF TTL would allow compaction optimizations (drop an entire sstable's worth of expired data) that we can't do with per-column. -- 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-4446) nodetool drain sometimes doesn't mark commitlog fully flushed
[ https://issues.apache.org/jira/browse/CASSANDRA-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Coli updated CASSANDRA-4446: --- Attachment: cassandra.1.0.10.replaying.log.after.exception.during.drain.txt nodetool drain sometimes doesn't mark commitlog fully flushed - Key: CASSANDRA-4446 URL: https://issues.apache.org/jira/browse/CASSANDRA-4446 Project: Cassandra Issue Type: New Feature Affects Versions: 1.0.10 Environment: ubuntu 10.04 64bit Linux HOSTNAME 2.6.32-345-ec2 #48-Ubuntu SMP Wed May 2 19:29:55 UTC 2012 x86_64 GNU/Linux sun JVM cassandra 1.0.10 installed from apache deb Reporter: Robert Coli Attachments: cassandra.1.0.10.replaying.log.after.exception.during.drain.txt I recently wiped a customer's QA cluster. I drained each node and verified that they were drained. When I restarted the nodes, I saw the commitlog replay create a memtable and then flush it. I have attached a sanitized log snippet from a representative node at the time. It appears to show the following : 1) Drain begins 2) Drain triggers flush 3) Flush triggers compaction 4) StorageService logs DRAINED message 5) compaction thread excepts 6) on restart, same CF creates a memtable 7) and then flushes it [1] The columnfamily involved in the replay in 7) is the CF for which the compaction thread excepted in 5). This seems to suggest a timing issue whereby the exception in 5) prevents the flush in 3) from marking all the segments flushed, causing them to replay after restart. [1] Isn't commitlog replay not supposed to automatically trigger a flush in modern cassandra? -- 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-4446) nodetool drain sometimes doesn't mark commitlog fully flushed
[ https://issues.apache.org/jira/browse/CASSANDRA-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Coli updated CASSANDRA-4446: --- Issue Type: Bug (was: New Feature) nodetool drain sometimes doesn't mark commitlog fully flushed - Key: CASSANDRA-4446 URL: https://issues.apache.org/jira/browse/CASSANDRA-4446 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.10 Environment: ubuntu 10.04 64bit Linux HOSTNAME 2.6.32-345-ec2 #48-Ubuntu SMP Wed May 2 19:29:55 UTC 2012 x86_64 GNU/Linux sun JVM cassandra 1.0.10 installed from apache deb Reporter: Robert Coli Attachments: cassandra.1.0.10.replaying.log.after.exception.during.drain.txt I recently wiped a customer's QA cluster. I drained each node and verified that they were drained. When I restarted the nodes, I saw the commitlog replay create a memtable and then flush it. I have attached a sanitized log snippet from a representative node at the time. It appears to show the following : 1) Drain begins 2) Drain triggers flush 3) Flush triggers compaction 4) StorageService logs DRAINED message 5) compaction thread excepts 6) on restart, same CF creates a memtable 7) and then flushes it [1] The columnfamily involved in the replay in 7) is the CF for which the compaction thread excepted in 5). This seems to suggest a timing issue whereby the exception in 5) prevents the flush in 3) from marking all the segments flushed, causing them to replay after restart. [1] Isn't commitlog replay not supposed to automatically trigger a flush in modern cassandra? -- 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-4446) nodetool drain sometimes doesn't mark commitlog fully flushed
[ https://issues.apache.org/jira/browse/CASSANDRA-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Coli updated CASSANDRA-4446: --- Description: I recently wiped a customer's QA cluster. I drained each node and verified that they were drained. When I restarted the nodes, I saw the commitlog replay create a memtable and then flush it. I have attached a sanitized log snippet from a representative node at the time. It appears to show the following : 1) Drain begins 2) Drain triggers flush 3) Flush triggers compaction 4) StorageService logs DRAINED message 5) compaction thread excepts 6) on restart, same CF creates a memtable 7) and then flushes it [1] The columnfamily involved in the replay in 7) is the CF for which the compaction thread excepted in 5). This seems to suggest a timing issue whereby the exception in 5) prevents the flush in 3) from marking all the segments flushed, causing them to replay after restart. In case it might be relevant, I did an online change of compaction strategy from Leveled to SizeTiered during the uptime period preceding this drain. [1] Isn't commitlog replay not supposed to automatically trigger a flush in modern cassandra? was: I recently wiped a customer's QA cluster. I drained each node and verified that they were drained. When I restarted the nodes, I saw the commitlog replay create a memtable and then flush it. I have attached a sanitized log snippet from a representative node at the time. It appears to show the following : 1) Drain begins 2) Drain triggers flush 3) Flush triggers compaction 4) StorageService logs DRAINED message 5) compaction thread excepts 6) on restart, same CF creates a memtable 7) and then flushes it [1] The columnfamily involved in the replay in 7) is the CF for which the compaction thread excepted in 5). This seems to suggest a timing issue whereby the exception in 5) prevents the flush in 3) from marking all the segments flushed, causing them to replay after restart. [1] Isn't commitlog replay not supposed to automatically trigger a flush in modern cassandra? nodetool drain sometimes doesn't mark commitlog fully flushed - Key: CASSANDRA-4446 URL: https://issues.apache.org/jira/browse/CASSANDRA-4446 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.10 Environment: ubuntu 10.04 64bit Linux HOSTNAME 2.6.32-345-ec2 #48-Ubuntu SMP Wed May 2 19:29:55 UTC 2012 x86_64 GNU/Linux sun JVM cassandra 1.0.10 installed from apache deb Reporter: Robert Coli Attachments: cassandra.1.0.10.replaying.log.after.exception.during.drain.txt I recently wiped a customer's QA cluster. I drained each node and verified that they were drained. When I restarted the nodes, I saw the commitlog replay create a memtable and then flush it. I have attached a sanitized log snippet from a representative node at the time. It appears to show the following : 1) Drain begins 2) Drain triggers flush 3) Flush triggers compaction 4) StorageService logs DRAINED message 5) compaction thread excepts 6) on restart, same CF creates a memtable 7) and then flushes it [1] The columnfamily involved in the replay in 7) is the CF for which the compaction thread excepted in 5). This seems to suggest a timing issue whereby the exception in 5) prevents the flush in 3) from marking all the segments flushed, causing them to replay after restart. In case it might be relevant, I did an online change of compaction strategy from Leveled to SizeTiered during the uptime period preceding this drain. [1] Isn't commitlog replay not supposed to automatically trigger a flush in modern cassandra? -- 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 Can't Modify Index Name problem on CF update patch by Pavel Yaskevich; reviewed by Yuki Morishita for CASSANDRA-4439
Updated Branches:
refs/heads/cassandra-1.1 7c982717a - 202f3940d
fix Can't Modify Index Name problem on CF update
patch by Pavel Yaskevich; reviewed by Yuki Morishita for CASSANDRA-4439
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/202f3940
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/202f3940
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/202f3940
Branch: refs/heads/cassandra-1.1
Commit: 202f3940dc35411f9b2351a026e859e487b94591
Parents: 7c98271
Author: Pavel Yaskevich xe...@apache.org
Authored: Tue Jul 17 17:18:46 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Thu Jul 19 01:15:28 2012 +0300
--
CHANGES.txt|1 +
.../org/apache/cassandra/config/CFMetaData.java| 22 +++
test/unit/org/apache/cassandra/cli/CliTest.java|8 +
3 files changed, 31 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/202f3940/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 67b5410..b2a9faf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -14,6 +14,7 @@
* change nanoTime() to currentTimeInMillis() in schema related code
(CASSANDRA-4432)
* add a token generation tool (CASSANDRA-3709)
* Fix LCS bug with sstable containing only 1 row (CASSANDRA-4411)
+ * fix Can't Modify Index Name problem on CF update (CASSANDRA-4439)
Merged from 1.0:
* allow dropping columns shadowed by not-yet-expired supercolumn or row
tombstones in PrecompactedRow (CASSANDRA-4396)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/202f3940/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index c6411af..5b3f227 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -862,6 +862,28 @@ public final class CFMetaData
*/
public void addDefaultIndexNames() throws ConfigurationException
{
+// if this is ColumnFamily update we need to add previously defined
index names to the existing columns first
+Integer cfId = Schema.instance.getId(ksName, cfName);
+if (cfId != null)
+{
+CFMetaData cfm = Schema.instance.getCFMetaData(cfId);
+
+for (Map.EntryByteBuffer, ColumnDefinition entry :
column_metadata.entrySet())
+{
+ColumnDefinition newDef = entry.getValue();
+
+if (!cfm.column_metadata.containsKey(entry.getKey()) ||
newDef.getIndexType() == null)
+continue;
+
+String oldIndexName =
cfm.column_metadata.get(entry.getKey()).getIndexName();
+
+if (newDef.getIndexName() != null
!oldIndexName.equals(newDef.getIndexName()))
+throw new ConfigurationException(Can't modify index name:
was ' + oldIndexName + ' changed to ' + newDef.getIndexName() + '.);
+
+newDef.setIndexName(oldIndexName);
+}
+}
+
SetString existingNames = existingIndexNames(null);
for (ColumnDefinition column : column_metadata.values())
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/202f3940/test/unit/org/apache/cassandra/cli/CliTest.java
--
diff --git a/test/unit/org/apache/cassandra/cli/CliTest.java
b/test/unit/org/apache/cassandra/cli/CliTest.java
index 756dc7f..c13cf01 100644
--- a/test/unit/org/apache/cassandra/cli/CliTest.java
+++ b/test/unit/org/apache/cassandra/cli/CliTest.java
@@ -39,6 +39,14 @@ public class CliTest extends SchemaLoader
// please add new statements here so they could be auto-runned by this
test.
private String[] statements = {
use TestKeySpace;,
+create column family SecondaryIndicesWithoutIdxName +
+ with comparator = UTF8Type +
+ and default_validation_class = UTF8Type +
+ and column_metadata = [{column_name: profileId,
validation_class: UTF8Type, index_type: KEYS}];,
+update column family SecondaryIndicesWithoutIdxName +
+ with column_metadata = +
+[{column_name: profileId, validation_class: UTF8Type,
index_type: KEYS}, +
+ {column_name: postedDate, validation_class: LongType}];,
create column family 123 with comparator=UTF8Type and
column_metadata=[{ column_name:world, validation_class:IntegerType,
index_type:0, index_name:IdxName }, +
[jira] [Commented] (CASSANDRA-4444) Failure to delete column families
[
https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417758#comment-13417758
]
David B commented on CASSANDRA-:
In the most recent test, it did delete the metadata. I wasn't aware of the
modifications introduced in CASSANDRA-4221--thanks for the pointer.
Running the same test multiple times yesterday, however, got the server into a
state where it would not delete the CF from keyspace metadata. I had to delete
and rebuild the system keyspace for the system to return to normal operation.
Symptoms were very similar to what is reported in
https://issues.apache.org/jira/browse/CASSANDRA-4431. Any chance they could be
related.
In the meantime I'll try to reproduce the erroneous state. Thanks for the quick
response!
Failure to delete column families
-
Key: CASSANDRA-
URL: https://issues.apache.org/jira/browse/CASSANDRA-
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Environment: 2 node cluster running on Ubuntu Precise
Reporter: David B
Assignee: Pavel Yaskevich
I have a two node cluster, and one keyspace defined as follows:
create keyspace SampleKeyspace with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2};
I then create a column family as follows:
create column family SampleFamily with caching = 'keys_only' and
key_validation_class = 'LongType' and compression_options = {
sstable_compression: SnappyCompressor, chunk_length_kb: 64 }
I stream SSTables through SStableLoader.
After the load is complete, compaction begins. During this time, I request a
drop of the family through cassandra-cli using drop column family
SampleFamily.
Cassandra-cli responds that schemas are in agreement. Looking on the file
system, however, the full set of data files are still found under
data/SampleFamily (in addition to the snapshot created on drop family).
There are no errors in either system or output logs.
--
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-4444) Failure to delete column families
[
https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417758#comment-13417758
]
David B edited comment on CASSANDRA- at 7/18/12 10:25 PM:
--
In the most recent test, it did delete the metadata. I wasn't aware of the
modifications introduced in CASSANDRA-4221--thanks for the pointer.
Running the same test multiple times yesterday, however, got the server into a
state where it would not delete the CF from keyspace metadata. I had to delete
and rebuild the system keyspace for the system to return to normal operation.
Symptoms were very similar to what is reported in
https://issues.apache.org/jira/browse/CASSANDRA-4431. Any chance they could be
related?
In the meantime I'll try to reproduce the erroneous state. Thanks for the quick
response!
was (Author: sj.climber):
In the most recent test, it did delete the metadata. I wasn't aware of the
modifications introduced in CASSANDRA-4221--thanks for the pointer.
Running the same test multiple times yesterday, however, got the server into a
state where it would not delete the CF from keyspace metadata. I had to delete
and rebuild the system keyspace for the system to return to normal operation.
Symptoms were very similar to what is reported in
https://issues.apache.org/jira/browse/CASSANDRA-4431. Any chance they could be
related.
In the meantime I'll try to reproduce the erroneous state. Thanks for the quick
response!
Failure to delete column families
-
Key: CASSANDRA-
URL: https://issues.apache.org/jira/browse/CASSANDRA-
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Environment: 2 node cluster running on Ubuntu Precise
Reporter: David B
Assignee: Pavel Yaskevich
I have a two node cluster, and one keyspace defined as follows:
create keyspace SampleKeyspace with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2};
I then create a column family as follows:
create column family SampleFamily with caching = 'keys_only' and
key_validation_class = 'LongType' and compression_options = {
sstable_compression: SnappyCompressor, chunk_length_kb: 64 }
I stream SSTables through SStableLoader.
After the load is complete, compaction begins. During this time, I request a
drop of the family through cassandra-cli using drop column family
SampleFamily.
Cassandra-cli responds that schemas are in agreement. Looking on the file
system, however, the full set of data files are still found under
data/SampleFamily (in addition to the snapshot created on drop family).
There are no errors in either system or output logs.
--
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-4444) Failure to delete column families
[
https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417764#comment-13417764
]
Pavel Yaskevich commented on CASSANDRA-:
Yeah, this was my second guess, CASSANDRA-4432 applies for all of schema
operations, can you try to apply CASSANDRA-4432 before running your test?
Failure to delete column families
-
Key: CASSANDRA-
URL: https://issues.apache.org/jira/browse/CASSANDRA-
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Environment: 2 node cluster running on Ubuntu Precise
Reporter: David B
Assignee: Pavel Yaskevich
I have a two node cluster, and one keyspace defined as follows:
create keyspace SampleKeyspace with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2};
I then create a column family as follows:
create column family SampleFamily with caching = 'keys_only' and
key_validation_class = 'LongType' and compression_options = {
sstable_compression: SnappyCompressor, chunk_length_kb: 64 }
I stream SSTables through SStableLoader.
After the load is complete, compaction begins. During this time, I request a
drop of the family through cassandra-cli using drop column family
SampleFamily.
Cassandra-cli responds that schemas are in agreement. Looking on the file
system, however, the full set of data files are still found under
data/SampleFamily (in addition to the snapshot created on drop family).
There are no errors in either system or output logs.
--
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: fixes small bug introduced by CASSANDRA-4439
Updated Branches: refs/heads/cassandra-1.1 202f3940d - e220efa2a fixes small bug introduced by CASSANDRA-4439 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e220efa2 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e220efa2 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e220efa2 Branch: refs/heads/cassandra-1.1 Commit: e220efa2a87c8232d87bdca9f2a02cfcef9f1a4c Parents: 202f394 Author: Pavel Yaskevich xe...@apache.org Authored: Thu Jul 19 01:49:46 2012 +0300 Committer: Pavel Yaskevich xe...@apache.org Committed: Thu Jul 19 01:49:46 2012 +0300 -- .../org/apache/cassandra/config/CFMetaData.java|3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e220efa2/src/java/org/apache/cassandra/config/CFMetaData.java -- diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java b/src/java/org/apache/cassandra/config/CFMetaData.java index 5b3f227..9d77912 100644 --- a/src/java/org/apache/cassandra/config/CFMetaData.java +++ b/src/java/org/apache/cassandra/config/CFMetaData.java @@ -877,6 +877,9 @@ public final class CFMetaData String oldIndexName = cfm.column_metadata.get(entry.getKey()).getIndexName(); +if (oldIndexName == null) +continue; + if (newDef.getIndexName() != null !oldIndexName.equals(newDef.getIndexName())) throw new ConfigurationException(Can't modify index name: was ' + oldIndexName + ' changed to ' + newDef.getIndexName() + '.);
[jira] [Commented] (CASSANDRA-4444) Failure to delete column families
[
https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417806#comment-13417806
]
David B commented on CASSANDRA-:
You mention CASSANDRA-4432 applies for all schema operations--doesn't the issue
manifest only randomly, though, based on the results returned by nanoTime()?
Are there any workarounds, instead of applying the patch?
At the moment I'm unfortunately unable to replace the current install (from the
1.1.2 deb packages) with a patched source build. I can probably arrange to do
this in the next few days, though.
Failure to delete column families
-
Key: CASSANDRA-
URL: https://issues.apache.org/jira/browse/CASSANDRA-
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Environment: 2 node cluster running on Ubuntu Precise
Reporter: David B
Assignee: Pavel Yaskevich
I have a two node cluster, and one keyspace defined as follows:
create keyspace SampleKeyspace with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2};
I then create a column family as follows:
create column family SampleFamily with caching = 'keys_only' and
key_validation_class = 'LongType' and compression_options = {
sstable_compression: SnappyCompressor, chunk_length_kb: 64 }
I stream SSTables through SStableLoader.
After the load is complete, compaction begins. During this time, I request a
drop of the family through cassandra-cli using drop column family
SampleFamily.
Cassandra-cli responds that schemas are in agreement. Looking on the file
system, however, the full set of data files are still found under
data/SampleFamily (in addition to the snapshot created on drop family).
There are no errors in either system or output logs.
--
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-4444) Failure to delete column families
[
https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417814#comment-13417814
]
Pavel Yaskevich commented on CASSANDRA-:
bq. You mention CASSANDRA-4432 applies for all schema operations--doesn't the
issue manifest only randomly, though, based on the results returned by
nanoTime()?
Yes, that manifests randomly, that is why we weren't able to track the issue
sooner. I don't think that there any workarounds available except applying the
patch.
Failure to delete column families
-
Key: CASSANDRA-
URL: https://issues.apache.org/jira/browse/CASSANDRA-
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Environment: 2 node cluster running on Ubuntu Precise
Reporter: David B
Assignee: Pavel Yaskevich
I have a two node cluster, and one keyspace defined as follows:
create keyspace SampleKeyspace with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2};
I then create a column family as follows:
create column family SampleFamily with caching = 'keys_only' and
key_validation_class = 'LongType' and compression_options = {
sstable_compression: SnappyCompressor, chunk_length_kb: 64 }
I stream SSTables through SStableLoader.
After the load is complete, compaction begins. During this time, I request a
drop of the family through cassandra-cli using drop column family
SampleFamily.
Cassandra-cli responds that schemas are in agreement. Looking on the file
system, however, the full set of data files are still found under
data/SampleFamily (in addition to the snapshot created on drop family).
There are no errors in either system or output logs.
--
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-2116) Separate out filesystem errors from generic IOErrors
[ https://issues.apache.org/jira/browse/CASSANDRA-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-2116: - Attachment: CASSANDRA-2116-v3.patch This should do it. Separate out filesystem errors from generic IOErrors Key: CASSANDRA-2116 URL: https://issues.apache.org/jira/browse/CASSANDRA-2116 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Chris Goffinet Assignee: Aleksey Yeschenko Fix For: 1.2 Attachments: 0001-Issue-2116-Replace-some-IOErrors-with-more-informati.patch, 0001-Separate-out-filesystem-errors-from-generic-IOErrors.patch, CASSANDRA-2116-v3.patch We throw IOErrors everywhere today in the codebase. We should separate out specific errors such as (reading, writing) from filesystem into FSReadError and FSWriteError. This makes it possible in the next ticket to allow certain failure modes (kill the server if reads or writes fail to disk). -- 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: remove dead assignment
Updated Branches:
refs/heads/trunk 201fe9441 - 7af91424d
remove dead assignment
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7af91424
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7af91424
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7af91424
Branch: refs/heads/trunk
Commit: 7af91424d9b2929a72138c3f8ee75e09256aa5ef
Parents: 201fe94
Author: Dave Brosius dbros...@apache.org
Authored: Wed Jul 18 21:18:21 2012 -0400
Committer: Dave Brosius dbros...@apache.org
Committed: Wed Jul 18 21:18:21 2012 -0400
--
src/java/org/apache/cassandra/db/SystemTable.java | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7af91424/src/java/org/apache/cassandra/db/SystemTable.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemTable.java
b/src/java/org/apache/cassandra/db/SystemTable.java
index 9634515..48d9151 100644
--- a/src/java/org/apache/cassandra/db/SystemTable.java
+++ b/src/java/org/apache/cassandra/db/SystemTable.java
@@ -159,7 +159,7 @@ public class SystemTable
{
String req = INSERT INTO system.%s (token_bytes, peer) VALUES
('%s', '%s');
String tokenBytes =
ByteBufferUtil.bytesToHex(p.getTokenFactory().toByteArray(token));
-processInternal(String.format(req, PEERS_CF, tokenBytes,
ep.getHostAddress()));
+processInternal(String.format(req, PEERS_CF, tokenBytes,
ep.getHostAddress()));
}
forceBlockingFlush(PEERS_CF);
}
@@ -175,7 +175,7 @@ public class SystemTable
{
String req = DELETE FROM system.%s WHERE token_bytes = '%s';
String tokenBytes =
ByteBufferUtil.bytesToHex(p.getTokenFactory().toByteArray(token));
-processInternal(String.format(req, PEERS_CF, tokenBytes));
+processInternal(String.format(req, PEERS_CF, tokenBytes));
}
forceBlockingFlush(PEERS_CF);
}
@@ -185,8 +185,6 @@ public class SystemTable
*/
public static synchronized void updateTokens(CollectionToken tokens)
{
-IPartitioner p = StorageService.getPartitioner();
-
String req = INSERT INTO system.%s (key, token_bytes) VALUES ('%s',
'%s');
String tokenBytes = ByteBufferUtil.bytesToHex(serializeTokens(tokens));
processInternal(String.format(req, LOCAL_CF, LOCAL_KEY, tokenBytes));
@@ -214,15 +212,15 @@ public class SystemTable
newToks.put(toks);
toks = newToks;
}
-
+
toks.putShort((short)tokenBytes.remaining());
toks.put(tokenBytes);
}
-
+
toks.flip();
return toks;
}
-
+
private static CollectionToken deserializeTokens(ByteBuffer tokenBytes)
{
ListToken tokens = new ArrayListToken();
[Cassandra Wiki] Update of HowToDebug by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The HowToDebug page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/HowToDebug?action=diffrev1=12rev2=13 2. All jars in lib -2. build/lib/jars/hadoop-core-*.jar, build/lib/jars/jna-*.jar, build/lib/jars/commons-logging-*.jar, build/lib/jars/pig-*.jar +2. build/lib/jars/hadoop-core-*.jar, build/lib/jars/jna-*.jar, build/lib/jars/commons-logging-*.jar, build/lib/jars/pig-*.jar, build/lib/apache-rat-*.jar 1. Create a Debug Configuration
