[jira] [Created] (CASSANDRA-2848) Make the Client API support passing down timeouts
Make the Client API support passing down timeouts - Key: CASSANDRA-2848 URL: https://issues.apache.org/jira/browse/CASSANDRA-2848 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Minor Having a max server RPC timeout is good for worst case, but many applications that have middleware in front of Cassandra, might have higher timeout requirements. In a fail fast environment, if my application starting at say the front-end, only has 20ms to process a request, and it must connect to X services down the stack, by the time it hits Cassandra, we might only have 10ms. I propose we provide the ability to specify the timeout on each call we do optionally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-957) convenience workflow for replacing dead node
[ https://issues.apache.org/jira/browse/CASSANDRA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-957: - Assignee: (was: Chris Goffinet) convenience workflow for replacing dead node Key: CASSANDRA-957 URL: https://issues.apache.org/jira/browse/CASSANDRA-957 Project: Cassandra Issue Type: Wish Components: Core, Tools Reporter: Jonathan Ellis Fix For: 1.0 Attachments: 0001-Support-bringing-back-a-node-to-the-cluster-that-exi.patch, 0002-Do-not-include-local-node-when-computing-workMap.patch Original Estimate: 24h Remaining Estimate: 24h Replacing a dead node with a new one is a common operation, but nodetool removetoken followed by bootstrap is inefficient (re-replicating data first to the remaining nodes, then to the new one) and manually bootstrapping to a token just less than the old one's, followed by nodetool removetoken is slightly painful and prone to manual errors. First question: how would you expose this in our tool ecosystem? It needs to be a startup-time option to the new node, so it can't be nodetool, and messing with the config xml definitely takes the convenience out. A one-off -DreplaceToken=XXY argument? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-957) convenience workflow for replacing dead node
[ https://issues.apache.org/jira/browse/CASSANDRA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056293#comment-13056293 ] Chris Goffinet commented on CASSANDRA-957: -- I am going to defer this to anyone else who would like to pick up this ticket. I just do not have the spare time to focus on this. convenience workflow for replacing dead node Key: CASSANDRA-957 URL: https://issues.apache.org/jira/browse/CASSANDRA-957 Project: Cassandra Issue Type: Wish Components: Core, Tools Reporter: Jonathan Ellis Fix For: 1.0 Attachments: 0001-Support-bringing-back-a-node-to-the-cluster-that-exi.patch, 0002-Do-not-include-local-node-when-computing-workMap.patch Original Estimate: 24h Remaining Estimate: 24h Replacing a dead node with a new one is a common operation, but nodetool removetoken followed by bootstrap is inefficient (re-replicating data first to the remaining nodes, then to the new one) and manually bootstrapping to a token just less than the old one's, followed by nodetool removetoken is slightly painful and prone to manual errors. First question: how would you expose this in our tool ecosystem? It needs to be a startup-time option to the new node, so it can't be nodetool, and messing with the config xml definitely takes the convenience out. A one-off -DreplaceToken=XXY argument? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2778) Unable to set compaction strategy in cli using create column family command
[
https://issues.apache.org/jira/browse/CASSANDRA-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050715#comment-13050715
]
Chris Goffinet commented on CASSANDRA-2778:
---
+1
Unable to set compaction strategy in cli using create column family command
---
Key: CASSANDRA-2778
URL: https://issues.apache.org/jira/browse/CASSANDRA-2778
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Alan Liang
Assignee: Alan Liang
Attachments:
0001-2778-allow-for-dynamic-changes-to-compaction-strateg.patch
The following command does not set compaction strategy and its options:
{code}
create column family Standard1
with comparator = BytesType
and compaction_strategy =
'org.apache.cassandra.db.compaction.TimestampBucketedCompactionStrategy'
and compaction_strategy_options = [{max_sstable_size:504857600,
retention_in_seconds:60}];
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2752) repair fails with java.io.EOFException
[ https://issues.apache.org/jira/browse/CASSANDRA-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13046897#comment-13046897 ] Chris Goffinet commented on CASSANDRA-2752: --- I am trying to track down a similar issue. Instead was bootstrapping a new node in my case. repair fails with java.io.EOFException -- Key: CASSANDRA-2752 URL: https://issues.apache.org/jira/browse/CASSANDRA-2752 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Terje Marthinussen Issuing repair on node 1 (1.10.42.81) in a cluster quickly fails with INFO [AntiEntropyStage:1] 2011-06-09 19:02:47,999 AntiEntropyService.java (line 234) Queueing comparison #Differencer #TreeRequest manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306fb46e, /1 .10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])] INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java (line 468) Endpoints somewhere/1.10.42.81 and /1.10.42.82 have 2 range(s) out of sync for (JP,XXX) on (Token(bytes[6e]),Token(bytes[313039])] INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java (line 485) Performing streaming repair of 2 ranges for #TreeRequest manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306 fb46e, /1.10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])] INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,030 StreamOut.java (line 173) Stream context metadata [/data/cassandra/node0/data/JP/XXX-g-3-Data.db sections=1 progress=0/36592 - 0%], 1 sstables. INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,031 StreamOutSession.java (line 174) Streaming to /1.10.42.82 ERROR [CompactionExecutor:9] 2011-06-09 19:02:48,970 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[CompactionExecutor:9,1,main] java.io.EOFException at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) at org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) On .82 ERROR [CompactionExecutor:12] 2011-06-09 19:02:48,051 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[CompactionExecutor:12,1,main] java.io.EOFException at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) at org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) ERROR [Thread-132] 2011-06-09 19:02:48,051 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[Thread-132,5,main] java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.io.EOFException at org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:152) at org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:63) at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93) Caused by: java.util.concurrent.ExecutionException: java.io.EOFException at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at
[jira] [Commented] (CASSANDRA-957) convenience workflow for replacing dead node
[ https://issues.apache.org/jira/browse/CASSANDRA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13045741#comment-13045741 ] Chris Goffinet commented on CASSANDRA-957: -- yes. ill post an update next week with an updated patchset. convenience workflow for replacing dead node Key: CASSANDRA-957 URL: https://issues.apache.org/jira/browse/CASSANDRA-957 Project: Cassandra Issue Type: Wish Components: Core, Tools Reporter: Jonathan Ellis Assignee: Chris Goffinet Fix For: 1.0 Attachments: 0001-Support-bringing-back-a-node-to-the-cluster-that-exi.patch, 0002-Do-not-include-local-node-when-computing-workMap.patch Original Estimate: 24h Remaining Estimate: 24h Replacing a dead node with a new one is a common operation, but nodetool removetoken followed by bootstrap is inefficient (re-replicating data first to the remaining nodes, then to the new one) and manually bootstrapping to a token just less than the old one's, followed by nodetool removetoken is slightly painful and prone to manual errors. First question: how would you expose this in our tool ecosystem? It needs to be a startup-time option to the new node, so it can't be nodetool, and messing with the config xml definitely takes the convenience out. A one-off -DreplaceToken=XXY argument? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2702) Extend Row Cache Provider support
[ https://issues.apache.org/jira/browse/CASSANDRA-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2702: -- Attachment: 0001-Support-passing-tableName-and-cfName-to-RowCacheProv.patch Extend Row Cache Provider support - Key: CASSANDRA-2702 URL: https://issues.apache.org/jira/browse/CASSANDRA-2702 Project: Cassandra Issue Type: Improvement Environment: Modify the row cache provider interface to pass in table and cfName to each provider. Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Attachments: 0001-Support-passing-tableName-and-cfName-to-RowCacheProv.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2702) Extend Row Cache Provider support
[ https://issues.apache.org/jira/browse/CASSANDRA-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2702: -- Reviewer: stuhood Extend Row Cache Provider support - Key: CASSANDRA-2702 URL: https://issues.apache.org/jira/browse/CASSANDRA-2702 Project: Cassandra Issue Type: Improvement Environment: Modify the row cache provider interface to pass in table and cfName to each provider. Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Attachments: 0001-Support-passing-tableName-and-cfName-to-RowCacheProv.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2702) Extend Row Cache Provider support
[ https://issues.apache.org/jira/browse/CASSANDRA-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2702: -- Attachment: (was: 0001-Support-passing-tableName-and-cfName-to-RowCacheProv.patch) Extend Row Cache Provider support - Key: CASSANDRA-2702 URL: https://issues.apache.org/jira/browse/CASSANDRA-2702 Project: Cassandra Issue Type: Improvement Environment: Modify the row cache provider interface to pass in table and cfName to each provider. Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Attachments: 0001-Support-passing-tableName-and-cfName-to-RowCacheProv.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2702) Extend Row Cache Provider support
[ https://issues.apache.org/jira/browse/CASSANDRA-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2702: -- Attachment: 0001-Support-passing-tableName-and-cfName-to-RowCacheProv.patch Extend Row Cache Provider support - Key: CASSANDRA-2702 URL: https://issues.apache.org/jira/browse/CASSANDRA-2702 Project: Cassandra Issue Type: Improvement Environment: Modify the row cache provider interface to pass in table and cfName to each provider. Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Attachments: 0001-Support-passing-tableName-and-cfName-to-RowCacheProv.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2702) Extend Row Cache Provider support
[ https://issues.apache.org/jira/browse/CASSANDRA-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet resolved CASSANDRA-2702. --- Resolution: Fixed Fix Version/s: 0.8.1 Extend Row Cache Provider support - Key: CASSANDRA-2702 URL: https://issues.apache.org/jira/browse/CASSANDRA-2702 Project: Cassandra Issue Type: Improvement Environment: Modify the row cache provider interface to pass in table and cfName to each provider. Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8.1 Attachments: 0001-Support-passing-tableName-and-cfName-to-RowCacheProv.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2701) Memcache Row Cache Provider
[ https://issues.apache.org/jira/browse/CASSANDRA-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13043175#comment-13043175 ] Chris Goffinet commented on CASSANDRA-2701: --- Sorry, yes after talking to Stu, I found that out. Either way, it can go into contrib, we use it and find it better for our workloads since we have a custom version of memcached. The other nice aspect is, we can do rolling restarts without affecting cache since it's own process. Memcache Row Cache Provider --- Key: CASSANDRA-2701 URL: https://issues.apache.org/jira/browse/CASSANDRA-2701 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Create a row cache provider that uses memcached. We would like to contribute our provider we wrote that we use in production. We co-locate memcached on every node, and utilize Cassandra's ability to do replication + routing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2721) nodetool statusthrift
nodetool statusthrift - Key: CASSANDRA-2721 URL: https://issues.apache.org/jira/browse/CASSANDRA-2721 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8.1 We noticed when calling nodetool statusthrift, while a node is starting up, it throws an exception. I think the proper behavior should be just return false, instead of throwing an exception if RPC server hasn't started yet. That way this stack trace won't have to be thrown in nodetool: Exception in thread main java.lang.IllegalStateException: No configured RPC daemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2721) nodetool statusthrift
[ https://issues.apache.org/jira/browse/CASSANDRA-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2721: -- Attachment: 0001-If-RPCServer-isn-t-started-just-return-false-instead.patch nodetool statusthrift - Key: CASSANDRA-2721 URL: https://issues.apache.org/jira/browse/CASSANDRA-2721 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8.0 Attachments: 0001-If-RPCServer-isn-t-started-just-return-false-instead.patch We noticed when calling nodetool statusthrift, while a node is starting up, it throws an exception. I think the proper behavior should be just return false, instead of throwing an exception if RPC server hasn't started yet. That way this stack trace won't have to be thrown in nodetool: Exception in thread main java.lang.IllegalStateException: No configured RPC daemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2721) nodetool statusthrift exception while node starts up
[ https://issues.apache.org/jira/browse/CASSANDRA-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2721: -- Summary: nodetool statusthrift exception while node starts up (was: nodetool statusthrift) nodetool statusthrift exception while node starts up Key: CASSANDRA-2721 URL: https://issues.apache.org/jira/browse/CASSANDRA-2721 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8.0 Attachments: 0001-If-RPCServer-isn-t-started-just-return-false-instead.patch We noticed when calling nodetool statusthrift, while a node is starting up, it throws an exception. I think the proper behavior should be just return false, instead of throwing an exception if RPC server hasn't started yet. That way this stack trace won't have to be thrown in nodetool: Exception in thread main java.lang.IllegalStateException: No configured RPC daemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2722) nodetool statusthrift
nodetool statusthrift - Key: CASSANDRA-2722 URL: https://issues.apache.org/jira/browse/CASSANDRA-2722 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8.1 Provide the status of thrift server, if it's running or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2721) nodetool statusthrift exception while node starts up
[ https://issues.apache.org/jira/browse/CASSANDRA-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041036#comment-13041036 ] Chris Goffinet commented on CASSANDRA-2721: --- Ah! I forgot to commit that patch. It was put in our build. CASSANDRA-2722 nodetool statusthrift exception while node starts up Key: CASSANDRA-2721 URL: https://issues.apache.org/jira/browse/CASSANDRA-2721 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8.1 Attachments: 0001-If-RPCServer-isn-t-started-just-return-false-instead.patch We noticed when calling nodetool statusthrift, while a node is starting up, it throws an exception. I think the proper behavior should be just return false, instead of throwing an exception if RPC server hasn't started yet. That way this stack trace won't have to be thrown in nodetool: Exception in thread main java.lang.IllegalStateException: No configured RPC daemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2721) nodetool statusthrift exception while node starts up
[ https://issues.apache.org/jira/browse/CASSANDRA-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2721: -- Fix Version/s: (was: 0.8.0) 0.8.1 nodetool statusthrift exception while node starts up Key: CASSANDRA-2721 URL: https://issues.apache.org/jira/browse/CASSANDRA-2721 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8.1 Attachments: 0001-If-RPCServer-isn-t-started-just-return-false-instead.patch We noticed when calling nodetool statusthrift, while a node is starting up, it throws an exception. I think the proper behavior should be just return false, instead of throwing an exception if RPC server hasn't started yet. That way this stack trace won't have to be thrown in nodetool: Exception in thread main java.lang.IllegalStateException: No configured RPC daemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2722) nodetool statusthrift
[ https://issues.apache.org/jira/browse/CASSANDRA-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2722: -- Attachment: 0001-Added-the-ability-to-check-thrift-status-in-nodetool.patch nodetool statusthrift - Key: CASSANDRA-2722 URL: https://issues.apache.org/jira/browse/CASSANDRA-2722 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8.1 Attachments: 0001-Added-the-ability-to-check-thrift-status-in-nodetool.patch Provide the status of thrift server, if it's running or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2721) nodetool statusthrift exception while node starts up
[ https://issues.apache.org/jira/browse/CASSANDRA-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2721: -- Reviewer: slebresne nodetool statusthrift exception while node starts up Key: CASSANDRA-2721 URL: https://issues.apache.org/jira/browse/CASSANDRA-2721 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8.1 Attachments: 0001-If-RPCServer-isn-t-started-just-return-false-instead.patch We noticed when calling nodetool statusthrift, while a node is starting up, it throws an exception. I think the proper behavior should be just return false, instead of throwing an exception if RPC server hasn't started yet. That way this stack trace won't have to be thrown in nodetool: Exception in thread main java.lang.IllegalStateException: No configured RPC daemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2722) nodetool statusthrift
[ https://issues.apache.org/jira/browse/CASSANDRA-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2722: -- Reviewer: slebresne nodetool statusthrift - Key: CASSANDRA-2722 URL: https://issues.apache.org/jira/browse/CASSANDRA-2722 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8.1 Attachments: 0001-Added-the-ability-to-check-thrift-status-in-nodetool.patch Provide the status of thrift server, if it's running or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2644) Make bootstrap retry
[ https://issues.apache.org/jira/browse/CASSANDRA-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2644: -- Reviewer: stuhood Make bootstrap retry Key: CASSANDRA-2644 URL: https://issues.apache.org/jira/browse/CASSANDRA-2644 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 beta 2 Reporter: Chris Goffinet Assignee: Chris Goffinet Fix For: 0.8.1 Attachments: 0001-Make-ExpiringMap-have-objects-with-specific-timeouts.patch, 0002-Make-bootstrap-retry-and-increment-timeout-for-every.patch We ran into a situation where we had rpc_timeout set to 1 second, and the node needing to compute the token took over a second (1.6 seconds). The bootstrapping node hangs forever without getting a token because the expiring map removes it before the reply comes back. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2644) Make bootstrap retry
[ https://issues.apache.org/jira/browse/CASSANDRA-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041045#comment-13041045 ] Chris Goffinet commented on CASSANDRA-2644: --- Made changes to 02 patch, and commited to 0.8.1. Thanks! Make bootstrap retry Key: CASSANDRA-2644 URL: https://issues.apache.org/jira/browse/CASSANDRA-2644 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 beta 2 Reporter: Chris Goffinet Assignee: Chris Goffinet Fix For: 0.8.1 Attachments: 0001-Make-ExpiringMap-have-objects-with-specific-timeouts.patch, 0002-Make-bootstrap-retry-and-increment-timeout-for-every.patch We ran into a situation where we had rpc_timeout set to 1 second, and the node needing to compute the token took over a second (1.6 seconds). The bootstrapping node hangs forever without getting a token because the expiring map removes it before the reply comes back. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2203) Class to measure real memory allocated for an object
[ https://issues.apache.org/jira/browse/CASSANDRA-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet resolved CASSANDRA-2203. --- Resolution: Fixed We have jamm now but wanted to leave this here for anyone who finds it useful. Class to measure real memory allocated for an object Key: CASSANDRA-2203 URL: https://issues.apache.org/jira/browse/CASSANDRA-2203 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Attachments: 0001-Class-to-measure-actual-object-size-for-Hotspot-JVM.patch We wanted to share a class we are using internally to measure actual object sizes for Hotspot VM. We've been using this on RowCache and Memtables. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2722) nodetool statusthrift
[ https://issues.apache.org/jira/browse/CASSANDRA-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041069#comment-13041069 ] Chris Goffinet commented on CASSANDRA-2722: --- Commited and updated patch to reflect comments. nodetool statusthrift - Key: CASSANDRA-2722 URL: https://issues.apache.org/jira/browse/CASSANDRA-2722 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8.1 Attachments: 0001-Added-the-ability-to-check-thrift-status-in-nodetool.patch Provide the status of thrift server, if it's running or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2723) Rows that don't exist get cached
Rows that don't exist get cached Key: CASSANDRA-2723 URL: https://issues.apache.org/jira/browse/CASSANDRA-2723 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor We noticed that rows that don't exist were getting cached anyway. We end up storing an empty CF in cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2723) Rows that don't exist get cached
[ https://issues.apache.org/jira/browse/CASSANDRA-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2723: -- Attachment: 0001-Reset-SSTII-in-EchoedRow-iterator-see-CASSANDRA-2653.patch Rows that don't exist get cached Key: CASSANDRA-2723 URL: https://issues.apache.org/jira/browse/CASSANDRA-2723 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8.1 Attachments: 0001-Do-not-cache-rows-that-do-not-exist.patch We noticed that rows that don't exist were getting cached anyway. We end up storing an empty CF in cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2723) Rows that don't exist get cached
[ https://issues.apache.org/jira/browse/CASSANDRA-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2723: -- Attachment: (was: 0001-Reset-SSTII-in-EchoedRow-iterator-see-CASSANDRA-2653.patch) Rows that don't exist get cached Key: CASSANDRA-2723 URL: https://issues.apache.org/jira/browse/CASSANDRA-2723 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8.1 Attachments: 0001-Do-not-cache-rows-that-do-not-exist.patch We noticed that rows that don't exist were getting cached anyway. We end up storing an empty CF in cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2723) Rows that don't exist get cached
[ https://issues.apache.org/jira/browse/CASSANDRA-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2723: -- Attachment: 0001-Do-not-cache-rows-that-do-not-exist.patch Rows that don't exist get cached Key: CASSANDRA-2723 URL: https://issues.apache.org/jira/browse/CASSANDRA-2723 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8.1 Attachments: 0001-Do-not-cache-rows-that-do-not-exist.patch We noticed that rows that don't exist were getting cached anyway. We end up storing an empty CF in cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2723) Rows that don't exist get cached
[ https://issues.apache.org/jira/browse/CASSANDRA-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2723: -- Attachment: 0001-Do-not-cache-rows-that-do-not-exist-v2.patch Rows that don't exist get cached Key: CASSANDRA-2723 URL: https://issues.apache.org/jira/browse/CASSANDRA-2723 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8.1 Attachments: 0001-Do-not-cache-rows-that-do-not-exist-v2.patch, 0001-Do-not-cache-rows-that-do-not-exist.patch We noticed that rows that don't exist were getting cached anyway. We end up storing an empty CF in cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2700) Row cache provider options
Row cache provider options -- Key: CASSANDRA-2700 URL: https://issues.apache.org/jira/browse/CASSANDRA-2700 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2701) Memcache Row Cache Provider
Memcache Row Cache Provider --- Key: CASSANDRA-2701 URL: https://issues.apache.org/jira/browse/CASSANDRA-2701 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Create a row cache provider that uses memcached. We would like to contribute our provider we wrote that we use in production. We co-locate memcached on every node, and utilize Cassandra's ability to do replication + routing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2702) Extend Row Cache Provider support
Extend Row Cache Provider support - Key: CASSANDRA-2702 URL: https://issues.apache.org/jira/browse/CASSANDRA-2702 Project: Cassandra Issue Type: Improvement Environment: Modify the row cache provider interface to pass in table and cfName to each provider. Reporter: Chris Goffinet Assignee: Chris Goffinet -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2702) Extend Row Cache Provider support
[ https://issues.apache.org/jira/browse/CASSANDRA-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2702: -- Priority: Minor (was: Major) Extend Row Cache Provider support - Key: CASSANDRA-2702 URL: https://issues.apache.org/jira/browse/CASSANDRA-2702 Project: Cassandra Issue Type: Improvement Environment: Modify the row cache provider interface to pass in table and cfName to each provider. Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2701) Memcache Row Cache Provider
[ https://issues.apache.org/jira/browse/CASSANDRA-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038923#comment-13038923 ] Chris Goffinet commented on CASSANDRA-2701: --- We don't use memcached then. For super wide rows, we are going to be working on the slice + filter patch, this is for time series data. We will use it for storing N number of columns. Memcache Row Cache Provider --- Key: CASSANDRA-2701 URL: https://issues.apache.org/jira/browse/CASSANDRA-2701 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Create a row cache provider that uses memcached. We would like to contribute our provider we wrote that we use in production. We co-locate memcached on every node, and utilize Cassandra's ability to do replication + routing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2701) Memcache Row Cache Provider
[ https://issues.apache.org/jira/browse/CASSANDRA-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038924#comment-13038924 ] Chris Goffinet commented on CASSANDRA-2701: --- You can also increase the size of how big you want objects in memcached to be (1MB) Memcache Row Cache Provider --- Key: CASSANDRA-2701 URL: https://issues.apache.org/jira/browse/CASSANDRA-2701 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Create a row cache provider that uses memcached. We would like to contribute our provider we wrote that we use in production. We co-locate memcached on every node, and utilize Cassandra's ability to do replication + routing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2701) Memcache Row Cache Provider
[ https://issues.apache.org/jira/browse/CASSANDRA-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038940#comment-13038940 ] Chris Goffinet commented on CASSANDRA-2701: --- At the moment, off-heap does not support LRU. We get that from memcached, we use it as write-through LRU cache. We also internally have special version of memcached that has better visibility statistics than current memcached does along with much better improvements that we plan to open source. We also like the fact we don't have to worry about specifying N of objects, and instead use MB. Right now, we see more overhead in Cassandra as a whole, before even worrying about the performance of connecting over localhost. We have some big room for improvement there before off-heap becomes attractive. We look at this as short-term solution, until off-heap supports LRU, and is much more than just malloc/free. Memcache Row Cache Provider --- Key: CASSANDRA-2701 URL: https://issues.apache.org/jira/browse/CASSANDRA-2701 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Create a row cache provider that uses memcached. We would like to contribute our provider we wrote that we use in production. We co-locate memcached on every node, and utilize Cassandra's ability to do replication + routing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2701) Memcache Row Cache Provider
[ https://issues.apache.org/jira/browse/CASSANDRA-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038940#comment-13038940 ] Chris Goffinet edited comment on CASSANDRA-2701 at 5/25/11 2:56 AM: At the moment, off-heap does not support LRU. We get that from memcached, we use it as write-through LRU cache. We also internally have special version of memcached that has better visibility statistics than current memcached does along with much better improvements that we plan to open source. We also like the fact we don't have to worry about specifying the max size # of objects, and instead use MB allocated. Right now, we see more overhead in Cassandra as a whole, before even worrying about the performance of connecting over localhost. We have room for improvement there before off-heap becomes attractive. We look at this as short-term solution, until off-heap supports LRU, provides better statistics, and is much more than just malloc/free. was (Author: lenn0x): At the moment, off-heap does not support LRU. We get that from memcached, we use it as write-through LRU cache. We also internally have special version of memcached that has better visibility statistics than current memcached does along with much better improvements that we plan to open source. We also like the fact we don't have to worry about specifying N of objects, and instead use MB. Right now, we see more overhead in Cassandra as a whole, before even worrying about the performance of connecting over localhost. We have room for improvement there before off-heap becomes attractive. We look at this as short-term solution, until off-heap supports LRU, provides better statistics, and is much more than just malloc/free. Memcache Row Cache Provider --- Key: CASSANDRA-2701 URL: https://issues.apache.org/jira/browse/CASSANDRA-2701 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Create a row cache provider that uses memcached. We would like to contribute our provider we wrote that we use in production. We co-locate memcached on every node, and utilize Cassandra's ability to do replication + routing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2116) Separate out filesystem errors from generic IOErrors
[ https://issues.apache.org/jira/browse/CASSANDRA-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035111#comment-13035111 ] Chris Goffinet commented on CASSANDRA-2116: --- Unfortunately the best we can get is IOError from Java. For example we use this patch to actually detect when our raid array dies, the OS will tell java to throw IOError. I think we should error on the side of, if data is corrupt, we should let the operator decide what mode he wants. For us, any errors or any corruption of data, we want to take the node out right away. We have been testing this in production for awhile and it works really well when disks die, and we also did tests involving removing drives from the system while it was serving traffic. The Read/Write classes was a similar idea of how the Hadoop code base handles this very issue. Separate out filesystem errors from generic IOErrors Key: CASSANDRA-2116 URL: https://issues.apache.org/jira/browse/CASSANDRA-2116 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Minor Fix For: 1.0 Attachments: 0001-Separate-out-filesystem-errors-from-generic-IOErrors.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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2644) Make bootstrap retry
Make bootstrap retry Key: CASSANDRA-2644 URL: https://issues.apache.org/jira/browse/CASSANDRA-2644 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 beta 2 Reporter: Chris Goffinet Assignee: Chris Goffinet We ran into a situation where we had rpc_timeout set to 1 second, and the node needing to compute the token took over a second (1.6 seconds). The bootstrapping node hangs forever without getting a token. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2644) Make bootstrap retry
[ https://issues.apache.org/jira/browse/CASSANDRA-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032715#comment-13032715 ] Chris Goffinet commented on CASSANDRA-2644: --- I have a patch for this I'll be adding within the next day. I make ExpiringMap support custom timeouts per object, and make bootstrap getToken retry, while exponentially increasing the timeout until retries is met. Make bootstrap retry Key: CASSANDRA-2644 URL: https://issues.apache.org/jira/browse/CASSANDRA-2644 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 beta 2 Reporter: Chris Goffinet Assignee: Chris Goffinet We ran into a situation where we had rpc_timeout set to 1 second, and the node needing to compute the token took over a second (1.6 seconds). The bootstrapping node hangs forever without getting a token. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2644) Make bootstrap retry
[ https://issues.apache.org/jira/browse/CASSANDRA-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2644: -- Description: We ran into a situation where we had rpc_timeout set to 1 second, and the node needing to compute the token took over a second (1.6 seconds). The bootstrapping node hangs forever without getting a token because the expiring map removes it before the reply comes back. (was: We ran into a situation where we had rpc_timeout set to 1 second, and the node needing to compute the token took over a second (1.6 seconds). The bootstrapping node hangs forever without getting a token.) Make bootstrap retry Key: CASSANDRA-2644 URL: https://issues.apache.org/jira/browse/CASSANDRA-2644 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 beta 2 Reporter: Chris Goffinet Assignee: Chris Goffinet We ran into a situation where we had rpc_timeout set to 1 second, and the node needing to compute the token took over a second (1.6 seconds). The bootstrapping node hangs forever without getting a token because the expiring map removes it before the reply comes back. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2644) Make bootstrap retry
[ https://issues.apache.org/jira/browse/CASSANDRA-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2644: -- Attachment: 0002-Make-bootstrap-retry-and-increment-timeout-for-every.patch 0001-Make-ExpiringMap-have-objects-with-specific-timeouts.patch Make bootstrap retry Key: CASSANDRA-2644 URL: https://issues.apache.org/jira/browse/CASSANDRA-2644 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 beta 2 Reporter: Chris Goffinet Assignee: Chris Goffinet Fix For: 0.8.1 Attachments: 0001-Make-ExpiringMap-have-objects-with-specific-timeouts.patch, 0002-Make-bootstrap-retry-and-increment-timeout-for-every.patch We ran into a situation where we had rpc_timeout set to 1 second, and the node needing to compute the token took over a second (1.6 seconds). The bootstrapping node hangs forever without getting a token because the expiring map removes it before the reply comes back. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030535#comment-13030535 ] Chris Goffinet commented on CASSANDRA-1902: --- Peter, Just to be clear, I know about the fsync + dirty buffers issue. My patch made sure to fsync data as it flushes. And this isn't related to what I was seeing, because I was watching the pages of SSTables that were all cold, slowly become hot during compaction. Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt, 1902-BufferedSegmentedFile-logandsleep.txt, 1902-formatted.txt, 1902-per-column-migration-rebase2.txt, 1902-per-column-migration.txt, CASSANDRA-1902-v10-trunk-rebased.patch, CASSANDRA-1902-v3.patch, CASSANDRA-1902-v4.patch, CASSANDRA-1902-v5.patch, CASSANDRA-1902-v6.patch, CASSANDRA-1902-v7.patch, CASSANDRA-1902-v8.patch, CASSANDRA-1902-v9-trunk-rebased.patch, CASSANDRA-1902-v9-trunk-with-jmx.patch, CASSANDRA-1902-v9-trunk.patch, CASSANDRA-1902-v9.patch Original Estimate: 32h Time Spent: 56h Remaining Estimate: 0h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. This is now important since CASSANDRA-1470 caches effectively nothing. For example an active CF being compacted hurts reads since nothing is cached in the new SSTable. The purpose of this ticket then is to make sure SOME data is cached from active CFs. This can be done my monitoring which Old SSTables are in the page cache and caching active rows in the New SStable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030547#comment-13030547 ] Chris Goffinet commented on CASSANDRA-1902: --- Just to give an update, I did manage to get the hints to work, as long as I called posix_fadvise on the previous read pair. The next problem unfortunately is that the kernel is ignoring the FADV_RANDOM flag I call when the file is open. So read ahead still applies and has an effec This causes problems, because a) its going to be different on many kernels b) I need to see if its even possible to find this value without searching through /proc). I am still going to be -1 on this patch because it's becoming more and more complex to try to manage the state of the page cache. We have other areas in the code as well (streaming of files) that we would need to support as well, because of the fact we aren't checking pages/and making sure we aren't polluting the cache there. In our production environment, we already see the effects of this. Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt, 1902-BufferedSegmentedFile-logandsleep.txt, 1902-formatted.txt, 1902-per-column-migration-rebase2.txt, 1902-per-column-migration.txt, CASSANDRA-1902-v10-trunk-rebased.patch, CASSANDRA-1902-v3.patch, CASSANDRA-1902-v4.patch, CASSANDRA-1902-v5.patch, CASSANDRA-1902-v6.patch, CASSANDRA-1902-v7.patch, CASSANDRA-1902-v8.patch, CASSANDRA-1902-v9-trunk-rebased.patch, CASSANDRA-1902-v9-trunk-with-jmx.patch, CASSANDRA-1902-v9-trunk.patch, CASSANDRA-1902-v9.patch Original Estimate: 32h Time Spent: 56h Remaining Estimate: 0h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. This is now important since CASSANDRA-1470 caches effectively nothing. For example an active CF being compacted hurts reads since nothing is cached in the new SSTable. The purpose of this ticket then is to make sure SOME data is cached from active CFs. This can be done my monitoring which Old SSTables are in the page cache and caching active rows in the New SStable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030013#comment-13030013 ] Chris Goffinet commented on CASSANDRA-1902: --- We've been testing this patch out for awhile with some modifications. It actually makes things worse. First off, it does not check if a page is hot/cold before reading. In our tests we went ahead and added that support so we can make sure pages stay in a consistent state. What we are seeing though is that the kernel is ignoring a small percent of hints on a set of pages during the compaction process. Because of this, this patch ends up migrating pages that it thinks are hot into the new SSTables over time. You can start to really see the effects when you are running for days and weeks. Unfortunately since the kernel is ignoring hints on some of the pages and we can't really have full control I am -1 on this ticket all together after spending weeks on this. We found just letting the OS deal with page management to be better. We originally thought this was going to be better, and in many synthetic benchmarks it has promise. But after running it in a real production system, the latency is much higher. Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt, 1902-BufferedSegmentedFile-logandsleep.txt, 1902-formatted.txt, 1902-per-column-migration-rebase2.txt, 1902-per-column-migration.txt, CASSANDRA-1902-v3.patch, CASSANDRA-1902-v4.patch, CASSANDRA-1902-v5.patch, CASSANDRA-1902-v6.patch, CASSANDRA-1902-v7.patch, CASSANDRA-1902-v8.patch, CASSANDRA-1902-v9-trunk-rebased.patch, CASSANDRA-1902-v9-trunk-with-jmx.patch, CASSANDRA-1902-v9-trunk.patch, CASSANDRA-1902-v9.patch Original Estimate: 32h Time Spent: 56h Remaining Estimate: 0h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. This is now important since CASSANDRA-1470 caches effectively nothing. For example an active CF being compacted hurts reads since nothing is cached in the new SSTable. The purpose of this ticket then is to make sure SOME data is cached from active CFs. This can be done my monitoring which Old SSTables are in the page cache and caching active rows in the New SStable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030125#comment-13030125 ] Chris Goffinet commented on CASSANDRA-1902: --- Peter, In the modifications I did for 1902, when we open up SSTable files for compaction, I run mincore across the file to determine which pages are hot already using the hooks in 1902. I use this information in rebuffer() to call DONTNEED on pages that were cold to begin with after a read() call. A percentage of hints given to pages is being ignored by the kernel. Since that page is now 'hot', when we need to mark the hot pages for the new SSTable, we migrate more than we need. For example, we did a test where we made sure that on memtable flushing, we called DONTNEED on entire file. We verified the flushed files were not in cache. Then when compaction kicked in, since all pages were cold, we should have new SSTables that are not in cache. What we observed was, the final file after a large series of flushes + compaction, ended up being 50% in page cache over a long period of time. Even we purposely told the OS we don't want the pages in cache (as we read them). Jake: So the problem with that approach is that we still need to make sure as we read data from disk, if the page is cold, it stays cold. Keeping statistics helps the approach of not migrating pages that were cold to hot, but since we still have to read the file during compaction we still need to call DONTNEED on pages that were cold to begin with. That is what is causing the issue, we know a page is cold up front, but the kernel is not respecting that DONTNEED. I thought it might be related to READ AHEAD, so I made sure to fadvise FADV_RANDOM, so that wasn't the issue either. Jonathan: Yeah we run with CASSANDRA-2156, that's helped us a lot for performance consistency. We have certain workloads that need to read data recently written, so we disabled calling posix_fadvise(fd, 0, 0) during memtable flushes. We actually found writing new data, and just letting the kernel manage the pages worked better than 1902 solution, because we were calling WILLNEED on pages that were never being read to begin with. One last thing to try would be keeping track of the last (offset, length) so after read() call fadvise on the previous pair instead of what I just read. The ignoring of hints might be related to the current refcount. I will try this out tonight and update the ticket. Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt, 1902-BufferedSegmentedFile-logandsleep.txt, 1902-formatted.txt, 1902-per-column-migration-rebase2.txt, 1902-per-column-migration.txt, CASSANDRA-1902-v10-trunk-rebased.patch, CASSANDRA-1902-v3.patch, CASSANDRA-1902-v4.patch, CASSANDRA-1902-v5.patch, CASSANDRA-1902-v6.patch, CASSANDRA-1902-v7.patch, CASSANDRA-1902-v8.patch, CASSANDRA-1902-v9-trunk-rebased.patch, CASSANDRA-1902-v9-trunk-with-jmx.patch, CASSANDRA-1902-v9-trunk.patch, CASSANDRA-1902-v9.patch Original Estimate: 32h Time Spent: 56h Remaining Estimate: 0h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. This is now important since CASSANDRA-1470 caches effectively nothing. For example an active CF being compacted hurts reads since nothing is cached in the new SSTable. The purpose of this ticket then is to make sure SOME data is cached from active CFs. This can be done my monitoring which Old SSTables are in the page cache and caching active rows in the New SStable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2612) Disable compaction throttling during bootstrap
Disable compaction throttling during bootstrap -- Key: CASSANDRA-2612 URL: https://issues.apache.org/jira/browse/CASSANDRA-2612 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Disable compaction throttling during bootstrap, doesn't make sense since the node is not getting traffic. Plus it makes it faster to bootstrap a node into ring. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2612) Disable compaction throttling during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2612: -- Affects Version/s: 0.8.0 beta 2 Fix Version/s: 0.8.0 beta 2 Disable compaction throttling during bootstrap -- Key: CASSANDRA-2612 URL: https://issues.apache.org/jira/browse/CASSANDRA-2612 Project: Cassandra Issue Type: Improvement Affects Versions: 0.8.0 beta 2 Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8.0 beta 2 Disable compaction throttling during bootstrap, doesn't make sense since the node is not getting traffic. Plus it makes it faster to bootstrap a node into ring. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2612) Disable compaction throttling during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2612: -- Attachment: 0001-CASSANDRA-2612-Disable-compaction-throttling-during-.patch Disable compaction throttling during bootstrap -- Key: CASSANDRA-2612 URL: https://issues.apache.org/jira/browse/CASSANDRA-2612 Project: Cassandra Issue Type: Improvement Affects Versions: 0.8.0 beta 2 Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8.0 beta 2 Attachments: 0001-CASSANDRA-2612-Disable-compaction-throttling-during-.patch Disable compaction throttling during bootstrap, doesn't make sense since the node is not getting traffic. Plus it makes it faster to bootstrap a node into ring. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2581) Rebuffer called excessively during seeks
[ https://issues.apache.org/jira/browse/CASSANDRA-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2581: -- Affects Version/s: 0.8.1 Rebuffer called excessively during seeks Key: CASSANDRA-2581 URL: https://issues.apache.org/jira/browse/CASSANDRA-2581 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.1 Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor When doing an strace tonight, I noticed during memtable flushes that we were only writing 1KB per every write() system call...After diving more into it, it's because of a bug in the seek() code. if (newPosition = bufferOffset + validBufferBytes || newPosition bufferOffset) vs. if (newPosition (bufferOffset + validBufferBytes) || newPosition bufferOffset) Two things I noticed, we shouldn't need to rebuffer if newPosition is equal to bufferOffset + validBufferBytes, second the evaluation was doing (newPosition = bufferOffset) + validBufferBytes which always seemed to be true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2581) Rebuffer called excessively during seeks
Rebuffer called excessively during seeks Key: CASSANDRA-2581 URL: https://issues.apache.org/jira/browse/CASSANDRA-2581 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor When doing an strace tonight, I noticed during memtable flushes that we were only writing 1KB per every write() system call...After diving more into it, it's because of a bug in the seek() code. if (newPosition = bufferOffset + validBufferBytes || newPosition bufferOffset) vs. if (newPosition (bufferOffset + validBufferBytes) || newPosition bufferOffset) Two things I noticed, we shouldn't need to rebuffer if newPosition is equal to bufferOffset + validBufferBytes, second the evaluation was doing (newPosition = bufferOffset) + validBufferBytes which always seemed to be true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2581) Rebuffer called excessively during seeks
[ https://issues.apache.org/jira/browse/CASSANDRA-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2581: -- Attachment: 0001-Rebuffer-called-excessively-during-seeks.patch Rebuffer called excessively during seeks Key: CASSANDRA-2581 URL: https://issues.apache.org/jira/browse/CASSANDRA-2581 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.1 Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Attachments: 0001-Rebuffer-called-excessively-during-seeks.patch When doing an strace tonight, I noticed during memtable flushes that we were only writing 1KB per every write() system call...After diving more into it, it's because of a bug in the seek() code. if (newPosition = bufferOffset + validBufferBytes || newPosition bufferOffset) vs. if (newPosition (bufferOffset + validBufferBytes) || newPosition bufferOffset) Two things I noticed, we shouldn't need to rebuffer if newPosition is equal to bufferOffset + validBufferBytes, second the evaluation was doing (newPosition = bufferOffset) + validBufferBytes which always seemed to be true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2444) Remove checkAllColumnFamilies on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2444: -- Attachment: 0001-CASSANDRA-2444-Remove-checking-all-column-families-o.patch Remove checkAllColumnFamilies on startup Key: CASSANDRA-2444 URL: https://issues.apache.org/jira/browse/CASSANDRA-2444 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Labels: compaction Fix For: 0.8.1 Attachments: 0001-CASSANDRA-2444-Remove-checking-all-column-families-o.patch We've ran into many times where we do not want compaction to run right away against CFs when booting up a node. If the node needs to compact, it will do so at the first flush -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2444) Remove checkAllColumnFamilies on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2444: -- Attachment: (was: 0001-CASSANDRA-2444-Provide-an-option-to-enable-disable-c.patch) Remove checkAllColumnFamilies on startup Key: CASSANDRA-2444 URL: https://issues.apache.org/jira/browse/CASSANDRA-2444 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Labels: compaction Fix For: 0.8.1 Attachments: 0001-CASSANDRA-2444-Remove-checking-all-column-families-o.patch We've ran into many times where we do not want compaction to run right away against CFs when booting up a node. If the node needs to compact, it will do so at the first flush -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2535) CQL create keyspace throws exceptions
CQL create keyspace throws exceptions
-
Key: CASSANDRA-2535
URL: https://issues.apache.org/jira/browse/CASSANDRA-2535
Project: Cassandra
Issue Type: Bug
Reporter: Chris Goffinet
Was trying out CQL:
cqlsh create keyspace foo with replication_factor=1 and
strategy_class='org.apache.cassandra.locator.SimpleStrategy';
Bad Request: org.apache.cassandra.config.ConfigurationException: SimpleStrategy
requires a replication_factor strategy option.
On Cassandra side:
INFO 15:41:14,423 Applying migration 768b63c0-6c68-11e0--242d50cf1fbf Add
keyspace: foorep strategy:SimpleStrategy{}
INFO 15:41:14,424 Enqueuing flush of Memtable-Migrations@17649447(6489/8111
serialized/live bytes, 1 ops)
INFO 15:41:14,425 Enqueuing flush of Memtable-Schema@186829279(2599/3248
serialized/live bytes, 3 ops)
INFO 15:41:14,425 Writing Memtable-Migrations@17649447(6489/8111
serialized/live bytes, 1 ops)
INFO 15:41:14,435 Completed flushing
/var/lib/cassandra/data/system/Migrations-f-1-Data.db (6553 bytes)
INFO 15:41:14,436 Writing Memtable-Schema@186829279(2599/3248 serialized/live
bytes, 3 ops)
INFO 15:41:14,449 Completed flushing
/var/lib/cassandra/data/system/Schema-f-1-Data.db (2749 bytes)
ERROR 15:41:14,452 Fatal exception in thread Thread[MigrationStage:1,5,main]
java.lang.RuntimeException: org.apache.cassandra.config.ConfigurationException:
SimpleStrategy requires a replication_factor strategy option.
at org.apache.cassandra.db.Table.init(Table.java:278)
at org.apache.cassandra.db.Table.open(Table.java:110)
at
org.apache.cassandra.db.migration.AddKeyspace.applyModels(AddKeyspace.java:74)
at org.apache.cassandra.db.migration.Migration.apply(Migration.java:154)
at
org.apache.cassandra.cql.QueryProcessor$1.call(QueryProcessor.java:339)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.apache.cassandra.config.ConfigurationException: SimpleStrategy
requires a replication_factor strategy option.
at
org.apache.cassandra.locator.SimpleStrategy.validateOptions(SimpleStrategy.java:79)
at
org.apache.cassandra.locator.AbstractReplicationStrategy.createReplicationStrategy(AbstractReplicationStrategy.java:262)
at
org.apache.cassandra.db.Table.createReplicationStrategy(Table.java:328)
at org.apache.cassandra.db.Table.init(Table.java:274)
... 9 more
INFO 15:41:37,210 Applying migration 843c7c70-6c68-11e0--242d50cf1fbf Drop
keyspace: foo
INFO 15:41:37,211 Enqueuing flush of Memtable-Migrations@1289702396(6372/7965
serialized/live bytes, 1 ops)
INFO 15:41:37,211 Writing Memtable-Migrations@1289702396(6372/7965
serialized/live bytes, 1 ops)
INFO 15:41:37,212 Enqueuing flush of Memtable-Schema@1475720401(2529/3161
serialized/live bytes, 2 ops)
INFO 15:41:37,222 Completed flushing
/var/lib/cassandra/data/system/Migrations-f-2-Data.db (6436 bytes)
INFO 15:41:37,223 Writing Memtable-Schema@1475720401(2529/3161 serialized/live
bytes, 2 ops)
INFO 15:41:37,244 Completed flushing
/var/lib/cassandra/data/system/Schema-f-2-Data.db (2679 bytes)
The keyspace gets created anyway and I can no longer drop it, I get this
message:
cqlsh drop keyspace foo;
Exception: TSocket read 0 bytes
ERROR 15:41:37,246 Fatal exception in thread Thread[MigrationStage:1,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.migration.DropKeyspace.applyModels(DropKeyspace.java:81)
at org.apache.cassandra.db.migration.Migration.apply(Migration.java:154)
at
org.apache.cassandra.cql.QueryProcessor$1.call(QueryProcessor.java:339)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
ERROR 15:41:37,246 Thrift error occurred during processing of message.
org.apache.thrift.protocol.TProtocolException: Required field 'why' was not
present! Struct: InvalidRequestException(why:null)
at
org.apache.cassandra.thrift.InvalidRequestException.validate(InvalidRequestException.java:334)
at
org.apache.cassandra.thrift.InvalidRequestException.write(InvalidRequestException.java:303)
at
org.apache.cassandra.thrift.Cassandra$execute_cql_query_result.write(Cassandra.java:32011)
at
[jira] [Updated] (CASSANDRA-2535) CQL create keyspace throws exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Goffinet updated CASSANDRA-2535:
--
Affects Version/s: 0.8 beta 1
CQL create keyspace throws exceptions
-
Key: CASSANDRA-2535
URL: https://issues.apache.org/jira/browse/CASSANDRA-2535
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8 beta 1
Reporter: Chris Goffinet
Labels: CQL
Was trying out CQL:
cqlsh create keyspace foo with replication_factor=1 and
strategy_class='org.apache.cassandra.locator.SimpleStrategy';
Bad Request: org.apache.cassandra.config.ConfigurationException:
SimpleStrategy requires a replication_factor strategy option.
On Cassandra side:
INFO 15:41:14,423 Applying migration 768b63c0-6c68-11e0--242d50cf1fbf
Add keyspace: foorep strategy:SimpleStrategy{}
INFO 15:41:14,424 Enqueuing flush of Memtable-Migrations@17649447(6489/8111
serialized/live bytes, 1 ops)
INFO 15:41:14,425 Enqueuing flush of Memtable-Schema@186829279(2599/3248
serialized/live bytes, 3 ops)
INFO 15:41:14,425 Writing Memtable-Migrations@17649447(6489/8111
serialized/live bytes, 1 ops)
INFO 15:41:14,435 Completed flushing
/var/lib/cassandra/data/system/Migrations-f-1-Data.db (6553 bytes)
INFO 15:41:14,436 Writing Memtable-Schema@186829279(2599/3248
serialized/live bytes, 3 ops)
INFO 15:41:14,449 Completed flushing
/var/lib/cassandra/data/system/Schema-f-1-Data.db (2749 bytes)
ERROR 15:41:14,452 Fatal exception in thread Thread[MigrationStage:1,5,main]
java.lang.RuntimeException:
org.apache.cassandra.config.ConfigurationException: SimpleStrategy requires a
replication_factor strategy option.
at org.apache.cassandra.db.Table.init(Table.java:278)
at org.apache.cassandra.db.Table.open(Table.java:110)
at
org.apache.cassandra.db.migration.AddKeyspace.applyModels(AddKeyspace.java:74)
at org.apache.cassandra.db.migration.Migration.apply(Migration.java:154)
at
org.apache.cassandra.cql.QueryProcessor$1.call(QueryProcessor.java:339)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.apache.cassandra.config.ConfigurationException: SimpleStrategy
requires a replication_factor strategy option.
at
org.apache.cassandra.locator.SimpleStrategy.validateOptions(SimpleStrategy.java:79)
at
org.apache.cassandra.locator.AbstractReplicationStrategy.createReplicationStrategy(AbstractReplicationStrategy.java:262)
at
org.apache.cassandra.db.Table.createReplicationStrategy(Table.java:328)
at org.apache.cassandra.db.Table.init(Table.java:274)
... 9 more
INFO 15:41:37,210 Applying migration 843c7c70-6c68-11e0--242d50cf1fbf
Drop keyspace: foo
INFO 15:41:37,211 Enqueuing flush of
Memtable-Migrations@1289702396(6372/7965 serialized/live bytes, 1 ops)
INFO 15:41:37,211 Writing Memtable-Migrations@1289702396(6372/7965
serialized/live bytes, 1 ops)
INFO 15:41:37,212 Enqueuing flush of Memtable-Schema@1475720401(2529/3161
serialized/live bytes, 2 ops)
INFO 15:41:37,222 Completed flushing
/var/lib/cassandra/data/system/Migrations-f-2-Data.db (6436 bytes)
INFO 15:41:37,223 Writing Memtable-Schema@1475720401(2529/3161
serialized/live bytes, 2 ops)
INFO 15:41:37,244 Completed flushing
/var/lib/cassandra/data/system/Schema-f-2-Data.db (2679 bytes)
The keyspace gets created anyway and I can no longer drop it, I get this
message:
cqlsh drop keyspace foo;
Exception: TSocket read 0 bytes
ERROR 15:41:37,246 Fatal exception in thread Thread[MigrationStage:1,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.migration.DropKeyspace.applyModels(DropKeyspace.java:81)
at org.apache.cassandra.db.migration.Migration.apply(Migration.java:154)
at
org.apache.cassandra.cql.QueryProcessor$1.call(QueryProcessor.java:339)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
ERROR 15:41:37,246 Thrift error occurred during processing of message.
org.apache.thrift.protocol.TProtocolException: Required field 'why' was not
present! Struct: InvalidRequestException(why:null)
at
[jira] [Updated] (CASSANDRA-2444) An option to disable compaction on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2444: -- Fix Version/s: 0.8.1 An option to disable compaction on startup -- Key: CASSANDRA-2444 URL: https://issues.apache.org/jira/browse/CASSANDRA-2444 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Labels: compaction Fix For: 0.8.1 We've ran into many times where we do not want compaction to run right away against CFs when booting up a node. I propose we make that an option in the config, so operators do not have to take the penalty of compacting right away, and can return the node as close to working state as possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2444) An option to disable compaction on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet reassigned CASSANDRA-2444: - Assignee: Chris Goffinet An option to disable compaction on startup -- Key: CASSANDRA-2444 URL: https://issues.apache.org/jira/browse/CASSANDRA-2444 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Labels: compaction Fix For: 0.8.1 We've ran into many times where we do not want compaction to run right away against CFs when booting up a node. I propose we make that an option in the config, so operators do not have to take the penalty of compacting right away, and can return the node as close to working state as possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2444) An option to disable compaction on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2444: -- Attachment: 0001-CASSANDRA-2444-Provide-an-option-to-enable-disable-c.patch An option to disable compaction on startup -- Key: CASSANDRA-2444 URL: https://issues.apache.org/jira/browse/CASSANDRA-2444 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Labels: compaction Fix For: 0.8.1 Attachments: 0001-CASSANDRA-2444-Provide-an-option-to-enable-disable-c.patch We've ran into many times where we do not want compaction to run right away against CFs when booting up a node. I propose we make that an option in the config, so operators do not have to take the penalty of compacting right away, and can return the node as close to working state as possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2521) Move away from Phantom References for Compaction/Memtable
Move away from Phantom References for Compaction/Memtable - Key: CASSANDRA-2521 URL: https://issues.apache.org/jira/browse/CASSANDRA-2521 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Minor http://wiki.apache.org/cassandra/MemtableSSTable Let's move to using reference counting instead of relying on GC to be called in StorageService. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020171#comment-13020171 ] Chris Goffinet commented on CASSANDRA-1902: --- CASSANDRA-1470 introduced a way to help not pollute page cache. It also didn't solve it 100% We realized that during compaction, DONTNEED is used when reading pages from existing SSTables. While compaction runs this will effectively make all hot pages in those files, which are still being served be marked to be removed from cache. So we certainly helped not pollute cache, we also effectively removed hot data as well while compaction runs. We need to modify this patch so that while reading pages on existing SSTables we be sure to not remove those hot pages during compaction. I am happy to open another ticket if that makes more sense. But I figured we could just go ahead and make this ticket support that functionality too. Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt, 1902-BufferedSegmentedFile-logandsleep.txt, 1902-formatted.txt, 1902-per-column-migration-rebase2.txt, 1902-per-column-migration.txt, CASSANDRA-1902-v3.patch, CASSANDRA-1902-v4.patch, CASSANDRA-1902-v5.patch, CASSANDRA-1902-v6.patch, CASSANDRA-1902-v7.patch, CASSANDRA-1902-v8.patch, CASSANDRA-1902-v9-trunk-rebased.patch, CASSANDRA-1902-v9-trunk-with-jmx.patch, CASSANDRA-1902-v9-trunk.patch, CASSANDRA-1902-v9.patch Original Estimate: 32h Time Spent: 56h Remaining Estimate: 0h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. This is now important since CASSANDRA-1470 caches effectively nothing. For example an active CF being compacted hurts reads since nothing is cached in the new SSTable. The purpose of this ticket then is to make sure SOME data is cached from active CFs. This can be done my monitoring which Old SSTables are in the page cache and caching active rows in the New SStable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020171#comment-13020171 ] Chris Goffinet edited comment on CASSANDRA-1902 at 4/15/11 3:19 AM: CASSANDRA-1470 introduced a way to help not pollute page cache. It also didn't solve it 100% We realized that during compaction, DONTNEED is used when reading pages from existing SSTables. While compaction runs this will effectively make all hot pages in those files, which are still being served be marked to be removed from cache. So we certainly helped not pollute cache by taking in cold data, we also effectively removed hot data as well while compaction runs. We need to modify this patch so that while reading pages on existing SSTables we be sure to not remove those hot pages during compaction. I am happy to open another ticket if that makes more sense. But I figured we could just go ahead and make this ticket support that functionality too. was (Author: lenn0x): CASSANDRA-1470 introduced a way to help not pollute page cache. It also didn't solve it 100% We realized that during compaction, DONTNEED is used when reading pages from existing SSTables. While compaction runs this will effectively make all hot pages in those files, which are still being served be marked to be removed from cache. So we certainly helped not pollute cache, we also effectively removed hot data as well while compaction runs. We need to modify this patch so that while reading pages on existing SSTables we be sure to not remove those hot pages during compaction. I am happy to open another ticket if that makes more sense. But I figured we could just go ahead and make this ticket support that functionality too. Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt, 1902-BufferedSegmentedFile-logandsleep.txt, 1902-formatted.txt, 1902-per-column-migration-rebase2.txt, 1902-per-column-migration.txt, CASSANDRA-1902-v3.patch, CASSANDRA-1902-v4.patch, CASSANDRA-1902-v5.patch, CASSANDRA-1902-v6.patch, CASSANDRA-1902-v7.patch, CASSANDRA-1902-v8.patch, CASSANDRA-1902-v9-trunk-rebased.patch, CASSANDRA-1902-v9-trunk-with-jmx.patch, CASSANDRA-1902-v9-trunk.patch, CASSANDRA-1902-v9.patch Original Estimate: 32h Time Spent: 56h Remaining Estimate: 0h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. This is now important since CASSANDRA-1470 caches effectively nothing. For example an active CF being compacted hurts reads since nothing is cached in the new SSTable. The purpose of this ticket then is to make sure SOME data is cached from active CFs. This can be done my monitoring which Old SSTables are in the page cache and caching active rows in the New SStable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2443) Stream key/row caches during bootstrap
Stream key/row caches during bootstrap -- Key: CASSANDRA-2443 URL: https://issues.apache.org/jira/browse/CASSANDRA-2443 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Minor When adding new nodes to an existing cluster, if we streamed key and row caches over right before node came into cluster, we could minimize the impact of a cold node, and reduce the time for the node to get 'warmed' up. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2444) An option to disable compaction on startup
An option to disable compaction on startup -- Key: CASSANDRA-2444 URL: https://issues.apache.org/jira/browse/CASSANDRA-2444 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Priority: Minor We've ran into many times where we do not want compaction to run right away against CFs when booting up a node. I propose we make that an option in the config, so operators do not have to take the penalty of compacting right away, and can return the node as close to working state as possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2437) ClusterTool throws exception for get_endpoints
ClusterTool throws exception for get_endpoints -- Key: CASSANDRA-2437 URL: https://issues.apache.org/jira/browse/CASSANDRA-2437 Project: Cassandra Issue Type: Bug Affects Versions: 0.8 Reporter: Chris Goffinet Assignee: Chris Goffinet Fix For: 0.8 ByteBuffer is not serializable over JMX. Exception in thread main java.lang.reflect.UndeclaredThrowableException at $Proxy0.getNaturalEndpoints(Unknown Source) at org.apache.cassandra.tools.NodeProbe.getEndpoints(NodeProbe.java:446) at org.apache.cassandra.tools.ClusterCmd.printEndpoints(ClusterCmd.java:146) at org.apache.cassandra.tools.ClusterCmd.main(ClusterCmd.java:240) Caused by: java.io.NotSerializableException: java.nio.HeapByteBuffer at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1338) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1146) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at java.rmi.MarshalledObject.init(MarshalledObject.java:101) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:990) at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288) ... 4 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2437) ClusterTool throws exception for get_endpoints
[ https://issues.apache.org/jira/browse/CASSANDRA-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2437: -- Attachment: 0001-CASSANDRA-2437-Support-a-byte-key-for-getNaturalEndp.patch ClusterTool throws exception for get_endpoints -- Key: CASSANDRA-2437 URL: https://issues.apache.org/jira/browse/CASSANDRA-2437 Project: Cassandra Issue Type: Bug Affects Versions: 0.8 Reporter: Chris Goffinet Assignee: Chris Goffinet Fix For: 0.8 Attachments: 0001-CASSANDRA-2437-Support-a-byte-key-for-getNaturalEndp.patch ByteBuffer is not serializable over JMX. Exception in thread main java.lang.reflect.UndeclaredThrowableException at $Proxy0.getNaturalEndpoints(Unknown Source) at org.apache.cassandra.tools.NodeProbe.getEndpoints(NodeProbe.java:446) at org.apache.cassandra.tools.ClusterCmd.printEndpoints(ClusterCmd.java:146) at org.apache.cassandra.tools.ClusterCmd.main(ClusterCmd.java:240) Caused by: java.io.NotSerializableException: java.nio.HeapByteBuffer at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1338) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1146) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at java.rmi.MarshalledObject.init(MarshalledObject.java:101) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:990) at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288) ... 4 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2324) Repair transfers more data than necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Goffinet updated CASSANDRA-2324:
--
Reviewer: lenn0x
Repair transfers more data than necessary
-
Key: CASSANDRA-2324
URL: https://issues.apache.org/jira/browse/CASSANDRA-2324
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.6
Reporter: Brandon Williams
Assignee: Sylvain Lebresne
Fix For: 0.8
Attachments: 0001-Make-repair-operate-over-a-node-token-range.patch
To repro: 3 node cluster, stress.java 1M rows with -x KEYS and -l 2. The
index is enough to make some mutations drop (about 20-30k total in my tests).
Repair afterwards will repair a large amount of ranges the first time.
However, each subsequent run will repair the same set of small ranges every
time. INDEXED_RANGE_SLICE in stress never fully works. Counting rows with
sstablekeys shows there are 2M rows total as expected, however when trying to
count the indexed keys, I get exceptions like:
{noformat}
Exception in thread main java.io.IOException: Key out of order!
DecoratedKey(101571366040797913119296586470838356016,
0707ab782c5b5029d28a5e6d508ef72f0222528b5e28da3b7787492679dc51b96f868e0746073e54bc173be927049d0f51e25a6a95b3268213b8969abf40cea7d7)
DecoratedKey(12639574763031545147067490818595764132,
0bc414be3093348a2ad389ed28f18f0cc9a044b2e98587848a0d289dae13ed0ad479c74654900eeffc6236)
at
org.apache.cassandra.tools.SSTableExport.enumeratekeys(SSTableExport.java:206)
at
org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:388)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1969) Use BB for row cache - To Improve GC performance.
[ https://issues.apache.org/jira/browse/CASSANDRA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013819#comment-13013819 ] Chris Goffinet commented on CASSANDRA-1969: --- Could we get a rebase on 1969-rollup-and-config on trunk? Use BB for row cache - To Improve GC performance. - Key: CASSANDRA-1969 URL: https://issues.apache.org/jira/browse/CASSANDRA-1969 Project: Cassandra Issue Type: Improvement Components: Core Environment: Linux and Mac Reporter: Vijay Assignee: Vijay Priority: Minor Attachments: 0001-Config-1969.txt, 0001-introduce-ICache-InstrumentingCache-IRowCacheProvider.txt, 0002-Update_existing-1965.txt, 0002-implement-SerializingCache.txt, 0002-implement-SerializingCacheV2.txt, 0003-New_Cache_Providers-1969.txt, 0003-add-ICache.isCopying-method.txt, 0004-Null-Check-and-duplicate-bb.txt, 0004-TestCase-1969.txt, 1969-rollup-and-config.txt, BB_Cache-1945.png, JMX-Cache-1945.png, Old_Cahce-1945.png, POC-0001-Config-1945.txt, POC-0002-Update_existing-1945.txt, POC-0003-New_Cache_Providers-1945.txt Java BB.allocateDirect() will allocate native memory out of the JVM and will help reducing the GC pressure in the JVM with a large Cache. From some of the basic tests it shows around 50% improvement than doing a normal Object cache. In addition this patch provide the users an option to choose BB.allocateDirect or store everything in the heap. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2399) Do not impact page cache during streaming
Do not impact page cache during streaming - Key: CASSANDRA-2399 URL: https://issues.apache.org/jira/browse/CASSANDRA-2399 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Minor If we could do similar work we have done for compaction on streaming for new nodes, it would help to not blow out page cache. This might not be possible since we are using transferTo() but we should at least investigate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2393) Ring changes should stream from the replicas that are losing responsibility
[ https://issues.apache.org/jira/browse/CASSANDRA-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011912#comment-13011912 ] Chris Goffinet commented on CASSANDRA-2393: --- From what I can tell, this should only effect counters w/ Repair on Write turned off. We should really stream from all replicas if you have ROW turned off.. Ring changes should stream from the replicas that are losing responsibility --- Key: CASSANDRA-2393 URL: https://issues.apache.org/jira/browse/CASSANDRA-2393 Project: Cassandra Issue Type: Bug Components: Core Reporter: Stu Hood Priority: Minor During a bootstrap or move operation, the replica that is leaving the replica set should be the preferred node to stream data to the node that is joining the replica set. Currently, an effectively random node will be chosen. Since the data held by the leaving node may not agree with the other replicas, it is important for consistency that it be the one that streams. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2393) Ring changes should stream from the replicas that are losing responsibility
[ https://issues.apache.org/jira/browse/CASSANDRA-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011912#comment-13011912 ] Chris Goffinet edited comment on CASSANDRA-2393 at 3/28/11 4:29 AM: From what I can tell, this should only effect counters w/ Repair on Write turned off. We just need to stream from the replica that is leaving. was (Author: lenn0x): From what I can tell, this should only effect counters w/ Repair on Write turned off. We should really stream from all replicas if you have ROW turned off.. Ring changes should stream from the replicas that are losing responsibility --- Key: CASSANDRA-2393 URL: https://issues.apache.org/jira/browse/CASSANDRA-2393 Project: Cassandra Issue Type: Bug Components: Core Reporter: Stu Hood Priority: Minor During a bootstrap or move operation, the replica that is leaving the replica set should be the preferred node to stream data to the node that is joining the replica set. Currently, an effectively random node will be chosen. Since the data held by the leaving node may not agree with the other replicas, it is important for consistency that it be the one that streams. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2392) Saving IndexSummaries to disk
Saving IndexSummaries to disk - Key: CASSANDRA-2392 URL: https://issues.apache.org/jira/browse/CASSANDRA-2392 Project: Cassandra Issue Type: Improvement Affects Versions: 0.8 Reporter: Chris Goffinet Priority: Minor For nodes with millions of keys, doing rolling restarts that take over 10 minutes per node can be painful if you have 100 node cluster. All of our time is spent on doing index summary computations on startup. It would be great if we could save those to disk as well. Our indexes are quite large. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1969) Use BB for row cache - To Improve GC performance.
[ https://issues.apache.org/jira/browse/CASSANDRA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001865#comment-13001865 ] Chris Goffinet commented on CASSANDRA-1969: --- Are you MaxDirectMemorySize by default is unlimited? I remember seeing the default was 64MB.. Use BB for row cache - To Improve GC performance. - Key: CASSANDRA-1969 URL: https://issues.apache.org/jira/browse/CASSANDRA-1969 Project: Cassandra Issue Type: Improvement Components: Core Environment: Linux and Mac Reporter: Vijay Assignee: Vijay Priority: Minor Attachments: 0001-Config-1969.txt, 0001-introduce-ICache-InstrumentingCache-IRowCacheProvider.txt, 0002-Update_existing-1965.txt, 0002-implement-SerializingCache.txt, 0002-implement-SerializingCacheV2.txt, 0003-New_Cache_Providers-1969.txt, 0003-add-ICache.isCopying-method.txt, 0004-Null-Check-and-duplicate-bb.txt, 0004-TestCase-1969.txt, 1969-rollup-and-config.txt, BB_Cache-1945.png, JMX-Cache-1945.png, Old_Cahce-1945.png, POC-0001-Config-1945.txt, POC-0002-Update_existing-1945.txt, POC-0003-New_Cache_Providers-1945.txt Java BB.allocateDirect() will allocate native memory out of the JVM and will help reducing the GC pressure in the JVM with a large Cache. From some of the basic tests it shows around 50% improvement than doing a normal Object cache. In addition this patch provide the users an option to choose BB.allocateDirect or store everything in the heap. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CASSANDRA-1969) Use BB for row cache - To Improve GC performance.
[ https://issues.apache.org/jira/browse/CASSANDRA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001865#comment-13001865 ] Chris Goffinet edited comment on CASSANDRA-1969 at 3/3/11 5:02 AM: --- Are you sure MaxDirectMemorySize by default is unlimited? I remember seeing the default was 64MB.. was (Author: lenn0x): Are you MaxDirectMemorySize by default is unlimited? I remember seeing the default was 64MB.. Use BB for row cache - To Improve GC performance. - Key: CASSANDRA-1969 URL: https://issues.apache.org/jira/browse/CASSANDRA-1969 Project: Cassandra Issue Type: Improvement Components: Core Environment: Linux and Mac Reporter: Vijay Assignee: Vijay Priority: Minor Attachments: 0001-Config-1969.txt, 0001-introduce-ICache-InstrumentingCache-IRowCacheProvider.txt, 0002-Update_existing-1965.txt, 0002-implement-SerializingCache.txt, 0002-implement-SerializingCacheV2.txt, 0003-New_Cache_Providers-1969.txt, 0003-add-ICache.isCopying-method.txt, 0004-Null-Check-and-duplicate-bb.txt, 0004-TestCase-1969.txt, 1969-rollup-and-config.txt, BB_Cache-1945.png, JMX-Cache-1945.png, Old_Cahce-1945.png, POC-0001-Config-1945.txt, POC-0002-Update_existing-1945.txt, POC-0003-New_Cache_Providers-1945.txt Java BB.allocateDirect() will allocate native memory out of the JVM and will help reducing the GC pressure in the JVM with a large Cache. From some of the basic tests it shows around 50% improvement than doing a normal Object cache. In addition this patch provide the users an option to choose BB.allocateDirect or store everything in the heap. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1969) Use BB for row cache - To Improve GC performance.
[
https://issues.apache.org/jira/browse/CASSANDRA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001868#comment-13001868
]
Chris Goffinet commented on CASSANDRA-1969:
---
Maybe I am missing something...
// A user-settable upper limit on the maximum amount of allocatable direct
// buffer memory. This value may be changed during VM initialization if
// java is launched with -XX:MaxDirectMemorySize=size.
//
// The initial value of this field is arbitrary; during JRE initialization
// it will be reset to the value specified on the command line, if any,
// otherwise to Runtime.getRuntime.maxDirectMemory().
//
private static long directMemory = 64 * 1024 * 1024;
// If this method is invoked during VM initialization, it initializes the
// maximum amount of allocatable direct buffer memory (in bytes) from the
// system property sun.nio.MaxDirectMemorySize. The system property will
// be removed when it is accessed.
//
// If this method is invoked after the VM is booted, it returns the
// maximum amount of allocatable direct buffer memory.
public static long maxDirectMemory() {
if (booted)
return directMemory;
Properties p = System.getProperties();
String s = (String)p.remove(sun.nio.MaxDirectMemorySize);
System.setProperties(p);
if (s != null) {
if (s.equals(-1)) {
// -XX:MaxDirectMemorySize not given, take default
directMemory = Runtime.getRuntime().maxMemory();
} else {
long l = Long.parseLong(s);
if (l -1)
directMemory = l;
}
}
return directMemory;
}
Use BB for row cache - To Improve GC performance.
-
Key: CASSANDRA-1969
URL: https://issues.apache.org/jira/browse/CASSANDRA-1969
Project: Cassandra
Issue Type: Improvement
Components: Core
Environment: Linux and Mac
Reporter: Vijay
Assignee: Vijay
Priority: Minor
Attachments: 0001-Config-1969.txt,
0001-introduce-ICache-InstrumentingCache-IRowCacheProvider.txt,
0002-Update_existing-1965.txt, 0002-implement-SerializingCache.txt,
0002-implement-SerializingCacheV2.txt, 0003-New_Cache_Providers-1969.txt,
0003-add-ICache.isCopying-method.txt, 0004-Null-Check-and-duplicate-bb.txt,
0004-TestCase-1969.txt, 1969-rollup-and-config.txt, BB_Cache-1945.png,
JMX-Cache-1945.png, Old_Cahce-1945.png, POC-0001-Config-1945.txt,
POC-0002-Update_existing-1945.txt, POC-0003-New_Cache_Providers-1945.txt
Java BB.allocateDirect() will allocate native memory out of the JVM and will
help reducing the GC pressure in the JVM with a large Cache.
From some of the basic tests it shows around 50% improvement than doing a
normal Object cache.
In addition this patch provide the users an option to choose
BB.allocateDirect or store everything in the heap.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2235) Counter AES performance issue
Counter AES performance issue - Key: CASSANDRA-2235 URL: https://issues.apache.org/jira/browse/CASSANDRA-2235 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Fix For: 0.8 We noticed tonight when trying out AES for Counters in trunk, there is a serious performance issue when inlining the SSTables. We found that the way we are seeking in the file, BRAF keeps flushing out its buffer of 8MB, and we call dfile.sync() on every row. We are finalizing a patch to write a new SSTable on rebuild, instead of inlining. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2236) Cli does not support updating replicate_on_write
Cli does not support updating replicate_on_write Key: CASSANDRA-2236 URL: https://issues.apache.org/jira/browse/CASSANDRA-2236 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8 Add support for updating a column families replicate on write setting. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2236) Cli does not support updating replicate_on_write
[ https://issues.apache.org/jira/browse/CASSANDRA-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2236: -- Attachment: 0001-cli-support-replicate_on_write-via-update-CF.patch Patch by Kelvin Kakugawa. Cli does not support updating replicate_on_write Key: CASSANDRA-2236 URL: https://issues.apache.org/jira/browse/CASSANDRA-2236 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.8 Attachments: 0001-cli-support-replicate_on_write-via-update-CF.patch Add support for updating a column families replicate on write setting. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2203) Class to measure real memory allocated for an object
Class to measure real memory allocated for an object Key: CASSANDRA-2203 URL: https://issues.apache.org/jira/browse/CASSANDRA-2203 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial We wanted to share a class we are using internally to measure actual object sizes for Hotspot VM. We've been using this on RowCache and Memtables. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2203) Class to measure real memory allocated for an object
[ https://issues.apache.org/jira/browse/CASSANDRA-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2203: -- Attachment: 0001-Class-to-measure-actual-object-size-for-Hotspot-JVM.patch This requires JSR305 and Guava. Contribution is from Attila Szegedi. Class to measure real memory allocated for an object Key: CASSANDRA-2203 URL: https://issues.apache.org/jira/browse/CASSANDRA-2203 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Attachments: 0001-Class-to-measure-actual-object-size-for-Hotspot-JVM.patch We wanted to share a class we are using internally to measure actual object sizes for Hotspot VM. We've been using this on RowCache and Memtables. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996145#comment-12996145 ] Chris Goffinet commented on CASSANDRA-1902: --- I'd like to propose a change that might work much better for longer compactions: We write out a new SSTable and using posix_fadvice (like we do today), and make sure nothing is in cache. After the file is done being written, we call getCachedPages() across all sstables used in compaction and compute which pages are hot AFTER compaction is complete. This would allow us to to then sweep through the new SSTable written and mark pages that were hot. If we do the process while file is being written and we have a compaction that might take an hour, by the time it's done, the cache could churn. Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: T Jake Luciani Fix For: 0.7.3 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt Original Estimate: 32h Time Spent: 24h Remaining Estimate: 8h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. First, add a method to MmappedSegmentFile: long[] pagesInPageCache() that uses the posix mincore() function to detect the offsets of pages for this file currently in page cache. Then add getActiveKeys() which uses underlying pagesInPageCache() to get the keys actually in the page cache. use getActiveKeys() to detect which SSTables being compacted are in the os cache and make sure the subsequent pages in the new compacted SSTable are kept in the page cache for these keys. This will minimize the impact of compacting a hot SSTable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996168#comment-12996168 ] Chris Goffinet commented on CASSANDRA-1902: --- If we have 1TB of data, with 4KB pages, we computed storing those as integers to about 500MB. Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: T Jake Luciani Fix For: 0.7.3 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt Original Estimate: 32h Time Spent: 24h Remaining Estimate: 8h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. First, add a method to MmappedSegmentFile: long[] pagesInPageCache() that uses the posix mincore() function to detect the offsets of pages for this file currently in page cache. Then add getActiveKeys() which uses underlying pagesInPageCache() to get the keys actually in the page cache. use getActiveKeys() to detect which SSTables being compacted are in the os cache and make sure the subsequent pages in the new compacted SSTable are kept in the page cache for these keys. This will minimize the impact of compacting a hot SSTable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996170#comment-12996170 ] Chris Goffinet commented on CASSANDRA-1902: --- That's worst case too. I don't know of anyone running a node with 1TB+ of memory. Since they would just be hot pages. Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: T Jake Luciani Fix For: 0.7.3 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt Original Estimate: 32h Time Spent: 24h Remaining Estimate: 8h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. First, add a method to MmappedSegmentFile: long[] pagesInPageCache() that uses the posix mincore() function to detect the offsets of pages for this file currently in page cache. Then add getActiveKeys() which uses underlying pagesInPageCache() to get the keys actually in the page cache. use getActiveKeys() to detect which SSTables being compacted are in the os cache and make sure the subsequent pages in the new compacted SSTable are kept in the page cache for these keys. This will minimize the impact of compacting a hot SSTable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996199#comment-12996199 ] Chris Goffinet edited comment on CASSANDRA-1902 at 2/18/11 1:52 AM: Couldn't we build a list when reading/writing of the SSTables the first time, so that after new SSTable write is finished, we just mmap through the page cache, and we already know the new locations on the first pass? was (Author: lenn0x): Couldn't we build a list when reading/writing of the mappings, so that after write is finished, we just mmap through the page cache, and we already know the new locations on the first pass? Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: T Jake Luciani Fix For: 0.7.3 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt Original Estimate: 32h Time Spent: 24h Remaining Estimate: 8h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. First, add a method to MmappedSegmentFile: long[] pagesInPageCache() that uses the posix mincore() function to detect the offsets of pages for this file currently in page cache. Then add getActiveKeys() which uses underlying pagesInPageCache() to get the keys actually in the page cache. use getActiveKeys() to detect which SSTables being compacted are in the os cache and make sure the subsequent pages in the new compacted SSTable are kept in the page cache for these keys. This will minimize the impact of compacting a hot SSTable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1902) Migrate cached pages during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996199#comment-12996199 ] Chris Goffinet commented on CASSANDRA-1902: --- Couldn't we build a list when reading/writing of the mappings, so that after write is finished, we just mmap through the page cache, and we already know the new locations on the first pass? Migrate cached pages during compaction --- Key: CASSANDRA-1902 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: T Jake Luciani Assignee: T Jake Luciani Fix For: 0.7.3 Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt Original Estimate: 32h Time Spent: 24h Remaining Estimate: 8h Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted CF during the compaction process. First, add a method to MmappedSegmentFile: long[] pagesInPageCache() that uses the posix mincore() function to detect the offsets of pages for this file currently in page cache. Then add getActiveKeys() which uses underlying pagesInPageCache() to get the keys actually in the page cache. use getActiveKeys() to detect which SSTables being compacted are in the os cache and make sure the subsequent pages in the new compacted SSTable are kept in the page cache for these keys. This will minimize the impact of compacting a hot SSTable. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2187) Cassandra Cli hangs forever if schema does not settle within timeout window
Cassandra Cli hangs forever if schema does not settle within timeout window --- Key: CASSANDRA-2187 URL: https://issues.apache.org/jira/browse/CASSANDRA-2187 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor validateSchemaIsSettled will hang in the while loop since we never update start if migrations never settle. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2187) Cassandra Cli hangs forever if schema does not settle within timeout window
[ https://issues.apache.org/jira/browse/CASSANDRA-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2187: -- Attachment: 0001-Fix-Cassandra-cli-to-respect-timeout-if-schema-does-.patch Cassandra Cli hangs forever if schema does not settle within timeout window --- Key: CASSANDRA-2187 URL: https://issues.apache.org/jira/browse/CASSANDRA-2187 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Attachments: 0001-Fix-Cassandra-cli-to-respect-timeout-if-schema-does-.patch validateSchemaIsSettled will hang in the while loop since we never update start if migrations never settle. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2178) Memtable Flush writers doesn't actually flush in parallel
Memtable Flush writers doesn't actually flush in parallel - Key: CASSANDRA-2178 URL: https://issues.apache.org/jira/browse/CASSANDRA-2178 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor The flushWriter JMXEnabledThreadPoolExecutor sets the core pool min to 1, and sets the LBQ to DatabaseDescriptor.getFlushWriters(). Increasing memtable_flush_writers should allow us to flush more in parallel. The pool will not grow until LBQ fills up to DatabaseDescriptor.getFlushWriters(). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2178) Memtable Flush writers doesn't actually flush in parallel
[ https://issues.apache.org/jira/browse/CASSANDRA-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2178: -- Affects Version/s: 0.8 0.7.2 Fix Version/s: 0.8 Memtable Flush writers doesn't actually flush in parallel - Key: CASSANDRA-2178 URL: https://issues.apache.org/jira/browse/CASSANDRA-2178 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.2, 0.8 Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8 Attachments: 0001-Set-the-core-min-pool-size-to-memtable_flush_writers.patch The flushWriter JMXEnabledThreadPoolExecutor sets the core pool min to 1, and sets the LBQ to DatabaseDescriptor.getFlushWriters(). Increasing memtable_flush_writers should allow us to flush more in parallel. The pool will not grow until LBQ fills up to DatabaseDescriptor.getFlushWriters(). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2178) Memtable Flush writers doesn't actually flush in parallel
[ https://issues.apache.org/jira/browse/CASSANDRA-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2178: -- Attachment: 0001-Set-the-core-min-pool-size-to-memtable_flush_writers.patch Memtable Flush writers doesn't actually flush in parallel - Key: CASSANDRA-2178 URL: https://issues.apache.org/jira/browse/CASSANDRA-2178 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.2, 0.8 Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8 Attachments: 0001-Set-the-core-min-pool-size-to-memtable_flush_writers.patch The flushWriter JMXEnabledThreadPoolExecutor sets the core pool min to 1, and sets the LBQ to DatabaseDescriptor.getFlushWriters(). Increasing memtable_flush_writers should allow us to flush more in parallel. The pool will not grow until LBQ fills up to DatabaseDescriptor.getFlushWriters(). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2178) Memtable Flush writers doesn't actually flush in parallel
[ https://issues.apache.org/jira/browse/CASSANDRA-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2178: -- Attachment: 0001-Set-the-core-min-pool-size-to-memtable_flush_writers-v2.patch Use a SynchronousQueue instead Memtable Flush writers doesn't actually flush in parallel - Key: CASSANDRA-2178 URL: https://issues.apache.org/jira/browse/CASSANDRA-2178 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.2, 0.8 Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8 Attachments: 0001-Set-the-core-min-pool-size-to-memtable_flush_writers-v2.patch, 0001-Set-the-core-min-pool-size-to-memtable_flush_writers.patch The flushWriter JMXEnabledThreadPoolExecutor sets the core pool min to 1, and sets the LBQ to DatabaseDescriptor.getFlushWriters(). Increasing memtable_flush_writers should allow us to flush more in parallel. The pool will not grow until LBQ fills up to DatabaseDescriptor.getFlushWriters(). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2178) Memtable Flush writers doesn't actually flush in parallel
[ https://issues.apache.org/jira/browse/CASSANDRA-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12995647#comment-12995647 ] Chris Goffinet commented on CASSANDRA-2178: --- commited to 0.7 and merged into trunk Memtable Flush writers doesn't actually flush in parallel - Key: CASSANDRA-2178 URL: https://issues.apache.org/jira/browse/CASSANDRA-2178 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.2, 0.8 Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.8 Attachments: 0001-Set-the-core-min-pool-size-to-memtable_flush_writers-v2.patch, 0001-Set-the-core-min-pool-size-to-memtable_flush_writers.patch The flushWriter JMXEnabledThreadPoolExecutor sets the core pool min to 1, and sets the LBQ to DatabaseDescriptor.getFlushWriters(). Increasing memtable_flush_writers should allow us to flush more in parallel. The pool will not grow until LBQ fills up to DatabaseDescriptor.getFlushWriters(). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (CASSANDRA-2178) Memtable Flush writers doesn't actually flush in parallel
[ https://issues.apache.org/jira/browse/CASSANDRA-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet resolved CASSANDRA-2178. --- Resolution: Fixed Fix Version/s: 0.7.3 Memtable Flush writers doesn't actually flush in parallel - Key: CASSANDRA-2178 URL: https://issues.apache.org/jira/browse/CASSANDRA-2178 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.2, 0.8 Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.7.3, 0.8 Attachments: 0001-Set-the-core-min-pool-size-to-memtable_flush_writers-v2.patch, 0001-Set-the-core-min-pool-size-to-memtable_flush_writers.patch The flushWriter JMXEnabledThreadPoolExecutor sets the core pool min to 1, and sets the LBQ to DatabaseDescriptor.getFlushWriters(). Increasing memtable_flush_writers should allow us to flush more in parallel. The pool will not grow until LBQ fills up to DatabaseDescriptor.getFlushWriters(). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2135) Add the ability to enable/disable Thrift through nodetool
Add the ability to enable/disable Thrift through nodetool - Key: CASSANDRA-2135 URL: https://issues.apache.org/jira/browse/CASSANDRA-2135 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2135) Add the ability to enable/disable Thrift through nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2135: -- Attachment: 0001-Support-enable-disable-of-Thrift-server-from-nodetoo.patch Add the ability to enable/disable Thrift through nodetool - Key: CASSANDRA-2135 URL: https://issues.apache.org/jira/browse/CASSANDRA-2135 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.7.1 Attachments: 0001-Support-enable-disable-of-Thrift-server-from-nodetoo.patch -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2141) Expose cassandra version in nodetool info
Expose cassandra version in nodetool info - Key: CASSANDRA-2141 URL: https://issues.apache.org/jira/browse/CASSANDRA-2141 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial Fix For: 0.7.1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2143) Uncaught exceptions counter
Uncaught exceptions counter --- Key: CASSANDRA-2143 URL: https://issues.apache.org/jira/browse/CASSANDRA-2143 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Trivial We should keep a counter that is exposed through JMX of how many errors occurred that were thrown in the uncaught exception handler. This allows us to do better alerting if an error occurred instead of grepping logs. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2130) Allow operator to pause/resume compaction through JMX/nodetool
Allow operator to pause/resume compaction through JMX/nodetool -- Key: CASSANDRA-2130 URL: https://issues.apache.org/jira/browse/CASSANDRA-2130 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Trivial There are cases where it would be helpful to pause/resume a compaction in process over JMX/nodetool. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2096) InternalException on system_update_column_family if column_metadata is not assigned
[ https://issues.apache.org/jira/browse/CASSANDRA-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991787#comment-12991787 ] Chris Goffinet commented on CASSANDRA-2096: --- Merged from 0.7 InternalException on system_update_column_family if column_metadata is not assigned --- Key: CASSANDRA-2096 URL: https://issues.apache.org/jira/browse/CASSANDRA-2096 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.1, 0.8 Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor Fix For: 0.7.1, 0.8 Attachments: 0001-Fix-internal-exception-when-not-passing-in-column_me.patch Steps to reproduce: Execute system_update_column_family without passing in column_metadata in CfDef object. Error: java.lang.NullPointerException at org.apache.cassandra.config.CFMetaData.convertToAvro(CFMetaData.java:827) at org.apache.cassandra.thrift.CassandraServer.system_update_column_family(CassandraServer.java:882) at org.apache.cassandra.thrift.Cassandra$Processor$system_update_column_family.process(Cassandra.java:4518) at org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:3227) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:167) 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:619) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
