[jira] Commented: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970102#action_12970102 ] Peter Schuller commented on CASSANDRA-1470: --- Just to clarify then; as jbellis surmised my comments where indeed based on the fact that writes will be synchronous. In particular, what write caching gives you normally is the ability to defer the actual writing such that: (1) future writes can be colesced with past writes which in the extreme case translates seek-bound I/O to huge slabs of sequential I/O (2) re-written pages aren't re-written on disk (3) it allows the program to continue (e.g. churning CPU) without interrupting to wait for disk I/O (4) It de-couples the size of individual writes the application happens to make from the way it gets written out to disk Using direct I/O in the general case is difficult because there is a lot of logic in the kernel to implement this in a way that works generally. But with cassandra, we: (1) are not concerned with re-writing pages (2) are not concerned with mixing seek-bound and streaming I/O (3) are specifically after writing large amounts of data and we can select when to flush in-memory buffers So the problem becomes easier. But still, each direct write will essentially behave like a write() followed by an fsync(), with the performance implications that has (though not necessarily exactly; e.g. an asynchronous write() followed by fsync() might sit in an i/o queue waiting if the fsync() doesn't highten the priority of the previous write etc - depending on exact kernel behavior and whatnot). As far as I know, given large chunks being written we really should be able to achieve similar throughputs as the background writing done by the kernel. With one major caveat: If the writing is single-threaded, the lack of an asynchronous syscall API means that the thread will not be able to keep busy with CPU bound activity while waiting for the actual write. So while the writing when it does happen really should have the potential to be efficient, if one does want to simultaneously be CPU bound in e.g. compaction, the writing would have to happen from a background thread. However, note that the CPU waiting is not necessarily as bad is it sounds. If your compaction is heavily CPU bound the effect will be small in relative terms because very little time is spent doing the I/O anyway. If the compaction is heavily disk bound, you don't really care anyway since any additional time spent spinning CPU is just going to *lessen* negative impacts of compaction because it decreases the effect on live traffic. The most significant effect should be seen when compaction is reasonably balanced between CPU and disk, and in the extreme case one should potentially see up to a halving of compaction speed in a situation without live traffic further delaying I/O. I hope I'm being clear :) (And definitely do correct me if I'm overlooking something.) I feel a bit bad commenting all the time without actually putting up any code... use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970103#action_12970103 ] Oleg Anastasyev commented on CASSANDRA-1470: Guys, may be I misunderstand something, but are we trying to make compaction writes faster ? This is background data maintenance process, and I think it is not very much important how fast is it. I think most important about it is how much it makes normal (read) requests serving slower, keeping valuable resources, especially memory, busy. Did we measured the impact of compaction on read requests of direct IO writes compaction vs old normal writes compaction ? use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Anastasyev updated CASSANDRA-1470: --- Comment: was deleted (was: Guys, may be I misunderstand something, but are we trying to make compaction writes faster ? This is background data maintenance process, and I think it is not very much important how fast is it. I think most important about it is how much it makes normal (read) requests serving slower, keeping valuable resources, especially memory, busy. Did we measured the impact of compaction on read requests of direct IO writes compaction vs old normal writes compaction ? ) use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1840) nodetool move caused the moved node to drop itself from 'nodetool ring' output; others think it's 'joining'
nodetool move caused the moved node to drop itself from 'nodetool ring' output; others think it's 'joining' --- Key: CASSANDRA-1840 URL: https://issues.apache.org/jira/browse/CASSANDRA-1840 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller I have a test cluster with three nodes on a very recent 0.7 (last few days branch). It has very little data in it (so maybe timing can be an issue given how fast operations complete). It was otherwise healthy; nodetool ring was consistent on all nodes and I had just run some compactions and 'repair' commands on all nodes repeatedly. I had a single client doing some reads/writes of single columns; nothing extreme (low load). When I did a 'nodetool move' the node exited the ring, stopped responding to thrift RPC, entered the ring again, and started accepting RPC requests via thrift. It reports in the log that it is joined. However, at this point 'nodetool ring' on the node I moved does *not* show its own location in the ring, and other nodes show it as 'joining' (with the new token, not the old token). I will include nodetool ring output and log output below. The situation was un-wedged by restarting the node that I had moved. After it started and a few seconds passed, nodetool ring looked correct on the node in question and other nodes now reported it as 'up' rather than 'joining'. Moved node said post-move (.61 in the below pastes is the node that I moved): Address Status State LoadOwnsToken 110288156320304836825416347816186393502 78.31.15.204Up Normal 224.34 KB 61.44% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 And the other two: Address Status State LoadOwnsToken 164957594472845753490452447750528540018 78.31.15.204Up Normal 224.34 KB 29.31% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 193.182.3.61Up Joining 194.76 KB 32.13% 164957594472845753490452447750528540018 Address Status State LoadOwnsToken 164957594472845753490452447750528540018 78.31.15.204Up Normal 224.34 KB 29.31% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 193.182.3.61Up Joining 194.76 KB 32.13% 164957594472845753490452447750528540018 I'll try reproducing a few times, and also merge latest 0.7. Here is some system log output from the node that got moved; it looks good to me: INFO [RMI TCP Connection(32)-193.182.3.61] 2010-12-10 09:38:17,560 StorageService.java (line 455) Leaving: sleeping 3 ms for pending range setup INFO [RMI TCP Connection(32)-193.182.3.61] 2010-12-10 09:38:47,564 StorageService.java (line 455) Leaving: streaming data to other nodes INFO [StreamStage:1] 2010-12-10 09:38:47,566 StreamOut.java (line 75) Beginning transfer to /78.31.15.204 INFO [StreamStage:1] 2010-12-10 09:38:47,566 StreamOut.java (line 98) Flushing memtables for KeyspaceSlask... INFO [StreamStage:1] 2010-12-10 09:38:47,567 ColumnFamilyStore.java (line 639) switching in a fresh Memtable for KeyValue at CommitLogContext(file='/var/lib/spotify-cassandra/slask/commitlog/CommitLog-1291973418600.log', position=2573610) INFO [StreamStage:1] 2010-12-10 09:38:47,567 ColumnFamilyStore.java (line 943) Enqueuing flush of memtable-keyva...@1131602880(370711 bytes, 5533 operations) INFO [FlushWriter:1] 2010-12-10 09:38:47,567 Memtable.java (line 155) Writing memtable-keyva...@1131602880(370711 bytes, 5533 operations) INFO [FlushWriter:1] 2010-12-10 09:38:47,599 Memtable.java (line 162) Completed flushing /var/lib/spotify-cassandra/slask/data/KeyspaceSlask/KeyValue-e-68-Data.db (15042 bytes) INFO [StreamStage:1] 2010-12-10 09:38:47,601 StreamOut.java (line 171) Stream context metadata [/var/lib/spotify-cassandra/slask/data/KeyspaceSlask/KeyValue-e-67-Data.db/(0,10094) progress=0/10094 - 0%, /var/lib/spotify-cassandra/slask/data/KeyspaceSlask/KeyValue-e-68-Data.db/(0,10094) progress=0/10094 - 0%], 2 sstables. INFO [StreamStage:1] 2010-12-10 09:38:47,601 StreamOutSession.java (line 175) Streaming to /78.31.15.204 INFO [StreamStage:1] 2010-12-10 09:38:47,601 StreamOut.java (line 75) Beginning transfer to
[jira] Commented: (CASSANDRA-1840) nodetool move caused the moved node to drop itself from 'nodetool ring' output; others think it's 'joining'
[ https://issues.apache.org/jira/browse/CASSANDRA-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970115#action_12970115 ] Peter Schuller commented on CASSANDRA-1840: --- I could reproduce it consistently. I tried once per node; in each case a restart was required. Still same after stopping all nodes and starting them from scratch. I will update to today's 0.7 branch and re-try. nodetool move caused the moved node to drop itself from 'nodetool ring' output; others think it's 'joining' --- Key: CASSANDRA-1840 URL: https://issues.apache.org/jira/browse/CASSANDRA-1840 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller I have a test cluster with three nodes on a very recent 0.7 (last few days branch). It has very little data in it (so maybe timing can be an issue given how fast operations complete). It was otherwise healthy; nodetool ring was consistent on all nodes and I had just run some compactions and 'repair' commands on all nodes repeatedly. I had a single client doing some reads/writes of single columns; nothing extreme (low load). When I did a 'nodetool move' the node exited the ring, stopped responding to thrift RPC, entered the ring again, and started accepting RPC requests via thrift. It reports in the log that it is joined. However, at this point 'nodetool ring' on the node I moved does *not* show its own location in the ring, and other nodes show it as 'joining' (with the new token, not the old token). I will include nodetool ring output and log output below. The situation was un-wedged by restarting the node that I had moved. After it started and a few seconds passed, nodetool ring looked correct on the node in question and other nodes now reported it as 'up' rather than 'joining'. Moved node said post-move (.61 in the below pastes is the node that I moved): Address Status State LoadOwnsToken 110288156320304836825416347816186393502 78.31.15.204Up Normal 224.34 KB 61.44% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 And the other two: Address Status State LoadOwnsToken 164957594472845753490452447750528540018 78.31.15.204Up Normal 224.34 KB 29.31% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 193.182.3.61Up Joining 194.76 KB 32.13% 164957594472845753490452447750528540018 Address Status State LoadOwnsToken 164957594472845753490452447750528540018 78.31.15.204Up Normal 224.34 KB 29.31% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 193.182.3.61Up Joining 194.76 KB 32.13% 164957594472845753490452447750528540018 I'll try reproducing a few times, and also merge latest 0.7. Here is some system log output from the node that got moved; it looks good to me: INFO [RMI TCP Connection(32)-193.182.3.61] 2010-12-10 09:38:17,560 StorageService.java (line 455) Leaving: sleeping 3 ms for pending range setup INFO [RMI TCP Connection(32)-193.182.3.61] 2010-12-10 09:38:47,564 StorageService.java (line 455) Leaving: streaming data to other nodes INFO [StreamStage:1] 2010-12-10 09:38:47,566 StreamOut.java (line 75) Beginning transfer to /78.31.15.204 INFO [StreamStage:1] 2010-12-10 09:38:47,566 StreamOut.java (line 98) Flushing memtables for KeyspaceSlask... INFO [StreamStage:1] 2010-12-10 09:38:47,567 ColumnFamilyStore.java (line 639) switching in a fresh Memtable for KeyValue at CommitLogContext(file='/var/lib/spotify-cassandra/slask/commitlog/CommitLog-1291973418600.log', position=2573610) INFO [StreamStage:1] 2010-12-10 09:38:47,567 ColumnFamilyStore.java (line 943) Enqueuing flush of memtable-keyva...@1131602880(370711 bytes, 5533 operations) INFO [FlushWriter:1] 2010-12-10 09:38:47,567 Memtable.java (line 155) Writing memtable-keyva...@1131602880(370711 bytes, 5533 operations) INFO [FlushWriter:1] 2010-12-10 09:38:47,599 Memtable.java (line 162) Completed flushing /var/lib/spotify-cassandra/slask/data/KeyspaceSlask/KeyValue-e-68-Data.db (15042 bytes) INFO
[jira] Updated: (CASSANDRA-1840) nodetool move caused the moved node to drop itself from 'nodetool ring' output; others think it's 'joining'
[ https://issues.apache.org/jira/browse/CASSANDRA-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Schuller updated CASSANDRA-1840: -- Priority: Minor (was: Major) nodetool move caused the moved node to drop itself from 'nodetool ring' output; others think it's 'joining' --- Key: CASSANDRA-1840 URL: https://issues.apache.org/jira/browse/CASSANDRA-1840 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Priority: Minor I have a test cluster with three nodes on a very recent 0.7 (last few days branch). It has very little data in it (so maybe timing can be an issue given how fast operations complete). It was otherwise healthy; nodetool ring was consistent on all nodes and I had just run some compactions and 'repair' commands on all nodes repeatedly. I had a single client doing some reads/writes of single columns; nothing extreme (low load). When I did a 'nodetool move' the node exited the ring, stopped responding to thrift RPC, entered the ring again, and started accepting RPC requests via thrift. It reports in the log that it is joined. However, at this point 'nodetool ring' on the node I moved does *not* show its own location in the ring, and other nodes show it as 'joining' (with the new token, not the old token). I will include nodetool ring output and log output below. The situation was un-wedged by restarting the node that I had moved. After it started and a few seconds passed, nodetool ring looked correct on the node in question and other nodes now reported it as 'up' rather than 'joining'. Moved node said post-move (.61 in the below pastes is the node that I moved): Address Status State LoadOwnsToken 110288156320304836825416347816186393502 78.31.15.204Up Normal 224.34 KB 61.44% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 And the other two: Address Status State LoadOwnsToken 164957594472845753490452447750528540018 78.31.15.204Up Normal 224.34 KB 29.31% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 193.182.3.61Up Joining 194.76 KB 32.13% 164957594472845753490452447750528540018 Address Status State LoadOwnsToken 164957594472845753490452447750528540018 78.31.15.204Up Normal 224.34 KB 29.31% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 193.182.3.61Up Joining 194.76 KB 32.13% 164957594472845753490452447750528540018 I'll try reproducing a few times, and also merge latest 0.7. Here is some system log output from the node that got moved; it looks good to me: INFO [RMI TCP Connection(32)-193.182.3.61] 2010-12-10 09:38:17,560 StorageService.java (line 455) Leaving: sleeping 3 ms for pending range setup INFO [RMI TCP Connection(32)-193.182.3.61] 2010-12-10 09:38:47,564 StorageService.java (line 455) Leaving: streaming data to other nodes INFO [StreamStage:1] 2010-12-10 09:38:47,566 StreamOut.java (line 75) Beginning transfer to /78.31.15.204 INFO [StreamStage:1] 2010-12-10 09:38:47,566 StreamOut.java (line 98) Flushing memtables for KeyspaceSlask... INFO [StreamStage:1] 2010-12-10 09:38:47,567 ColumnFamilyStore.java (line 639) switching in a fresh Memtable for KeyValue at CommitLogContext(file='/var/lib/spotify-cassandra/slask/commitlog/CommitLog-1291973418600.log', position=2573610) INFO [StreamStage:1] 2010-12-10 09:38:47,567 ColumnFamilyStore.java (line 943) Enqueuing flush of memtable-keyva...@1131602880(370711 bytes, 5533 operations) INFO [FlushWriter:1] 2010-12-10 09:38:47,567 Memtable.java (line 155) Writing memtable-keyva...@1131602880(370711 bytes, 5533 operations) INFO [FlushWriter:1] 2010-12-10 09:38:47,599 Memtable.java (line 162) Completed flushing /var/lib/spotify-cassandra/slask/data/KeyspaceSlask/KeyValue-e-68-Data.db (15042 bytes) INFO [StreamStage:1] 2010-12-10 09:38:47,601 StreamOut.java (line 171) Stream context metadata [/var/lib/spotify-cassandra/slask/data/KeyspaceSlask/KeyValue-e-67-Data.db/(0,10094) progress=0/10094 - 0%,
[jira] Commented: (CASSANDRA-1840) nodetool move caused the moved node to drop itself from 'nodetool ring' output; others think it's 'joining'
[ https://issues.apache.org/jira/browse/CASSANDRA-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970126#action_12970126 ] Peter Schuller commented on CASSANDRA-1840: --- I am not able to reproduce with latest 0.7, though I'm not sure which change is expected to fix this problem so I'm not marking resolved yet until someone else does it or weighs in. nodetool move caused the moved node to drop itself from 'nodetool ring' output; others think it's 'joining' --- Key: CASSANDRA-1840 URL: https://issues.apache.org/jira/browse/CASSANDRA-1840 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Priority: Minor I have a test cluster with three nodes on a very recent 0.7 (last few days branch). It has very little data in it (so maybe timing can be an issue given how fast operations complete). It was otherwise healthy; nodetool ring was consistent on all nodes and I had just run some compactions and 'repair' commands on all nodes repeatedly. I had a single client doing some reads/writes of single columns; nothing extreme (low load). When I did a 'nodetool move' the node exited the ring, stopped responding to thrift RPC, entered the ring again, and started accepting RPC requests via thrift. It reports in the log that it is joined. However, at this point 'nodetool ring' on the node I moved does *not* show its own location in the ring, and other nodes show it as 'joining' (with the new token, not the old token). I will include nodetool ring output and log output below. The situation was un-wedged by restarting the node that I had moved. After it started and a few seconds passed, nodetool ring looked correct on the node in question and other nodes now reported it as 'up' rather than 'joining'. Moved node said post-move (.61 in the below pastes is the node that I moved): Address Status State LoadOwnsToken 110288156320304836825416347816186393502 78.31.15.204Up Normal 224.34 KB 61.44% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 And the other two: Address Status State LoadOwnsToken 164957594472845753490452447750528540018 78.31.15.204Up Normal 224.34 KB 29.31% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 193.182.3.61Up Joining 194.76 KB 32.13% 164957594472845753490452447750528540018 Address Status State LoadOwnsToken 164957594472845753490452447750528540018 78.31.15.204Up Normal 224.34 KB 29.31% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 193.182.3.61Up Joining 194.76 KB 32.13% 164957594472845753490452447750528540018 I'll try reproducing a few times, and also merge latest 0.7. Here is some system log output from the node that got moved; it looks good to me: INFO [RMI TCP Connection(32)-193.182.3.61] 2010-12-10 09:38:17,560 StorageService.java (line 455) Leaving: sleeping 3 ms for pending range setup INFO [RMI TCP Connection(32)-193.182.3.61] 2010-12-10 09:38:47,564 StorageService.java (line 455) Leaving: streaming data to other nodes INFO [StreamStage:1] 2010-12-10 09:38:47,566 StreamOut.java (line 75) Beginning transfer to /78.31.15.204 INFO [StreamStage:1] 2010-12-10 09:38:47,566 StreamOut.java (line 98) Flushing memtables for KeyspaceSlask... INFO [StreamStage:1] 2010-12-10 09:38:47,567 ColumnFamilyStore.java (line 639) switching in a fresh Memtable for KeyValue at CommitLogContext(file='/var/lib/spotify-cassandra/slask/commitlog/CommitLog-1291973418600.log', position=2573610) INFO [StreamStage:1] 2010-12-10 09:38:47,567 ColumnFamilyStore.java (line 943) Enqueuing flush of memtable-keyva...@1131602880(370711 bytes, 5533 operations) INFO [FlushWriter:1] 2010-12-10 09:38:47,567 Memtable.java (line 155) Writing memtable-keyva...@1131602880(370711 bytes, 5533 operations) INFO [FlushWriter:1] 2010-12-10 09:38:47,599 Memtable.java (line 162) Completed flushing /var/lib/spotify-cassandra/slask/data/KeyspaceSlask/KeyValue-e-68-Data.db (15042 bytes) INFO
[jira] Updated: (CASSANDRA-1838) Add ability to set TTL on columns in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1838: --- Attachment: CASSANDRA-1838.patch Add ability to set TTL on columns in cassandra-cli -- Key: CASSANDRA-1838 URL: https://issues.apache.org/jira/browse/CASSANDRA-1838 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.7.0 rc 1 Environment: Ubuntu 10.04 64bit Reporter: Eric Tamme Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.1 Attachments: CASSANDRA-1838.patch Currently the cassandra-cli does not have any mechanism to set the ttl attribute of a column. This would be a useful ability to have when working with the cli tool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1838) Add ability to set TTL on columns in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970136#action_12970136 ] Sylvain Lebresne commented on CASSANDRA-1838: - Pavel: it would be nice to actually show the ttl of a column when it has one (and by that I mean when you get a column) Add ability to set TTL on columns in cassandra-cli -- Key: CASSANDRA-1838 URL: https://issues.apache.org/jira/browse/CASSANDRA-1838 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.7.0 rc 1 Environment: Ubuntu 10.04 64bit Reporter: Eric Tamme Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.1 Attachments: CASSANDRA-1838.patch Currently the cassandra-cli does not have any mechanism to set the ttl attribute of a column. This would be a useful ability to have when working with the cli tool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1838) Add ability to set TTL on columns in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970137#action_12970137 ] Pavel Yaskevich commented on CASSANDRA-1838: Sure thing. Can you please post an example output here, how you see this? Add ability to set TTL on columns in cassandra-cli -- Key: CASSANDRA-1838 URL: https://issues.apache.org/jira/browse/CASSANDRA-1838 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.7.0 rc 1 Environment: Ubuntu 10.04 64bit Reporter: Eric Tamme Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.1 Attachments: CASSANDRA-1838.patch Currently the cassandra-cli does not have any mechanism to set the ttl attribute of a column. This would be a useful ability to have when working with the cli tool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1838) Add ability to set TTL on columns in cassandra-cli
[
https://issues.apache.org/jira/browse/CASSANDRA-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970138#action_12970138
]
Sylvain Lebresne commented on CASSANDRA-1838:
-
Nothing fancy, something like
{noformat}
[defa...@demo] get test2[row1];
= (column=col1, value=val1, timestamp=1291980736812000)
= (column=col2, value=val2, timestamp=1291980747061000,ttl=30)
{noformat}
Add ability to set TTL on columns in cassandra-cli
--
Key: CASSANDRA-1838
URL: https://issues.apache.org/jira/browse/CASSANDRA-1838
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 0.7.0 rc 1
Environment: Ubuntu 10.04 64bit
Reporter: Eric Tamme
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.7.1
Attachments: CASSANDRA-1838.patch
Currently the cassandra-cli does not have any mechanism to set the ttl
attribute of a column. This would be a useful ability to have when working
with the cli tool.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Cassandra Wiki] Trivial Update of ThomasBoose by Tho masBoose
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ThomasBoose page has been changed by ThomasBoose.
The comment on this change is: Start.
http://wiki.apache.org/cassandra/ThomasBoose
--
New page:
#format wiki
#language en
== Thomas Boose ==
Email: MailTo(thomas AT boose DOT nl)
{{http://a0.twimg.com/profile_images/196967692/Thomas_reasonably_small.jpg}}
Hi, I'm contributing to this wiki as part of a assignment by my university. The
asignment is to develop, design, build and implement a messaging system's
database backend for realtime, location based content provided by schools,
company's and individuals aim't at intrestgroups.
We have chosen cassandra for storage and now our task is to convert a
relational model into Cassandra columnfamily's. Therefore I'd like to create a
page describing how to implement specific EERD modeling parts to Cassandra.
I've read that not everybody supports this idea but I'd like to try it anyway.
Comments and sugestions are alway's welcome. Language improvevents are
appreciated as my native tonque is not english.
CategoryHomepage
[jira] Updated: (CASSANDRA-1838) Add ability to set TTL on columns in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1838: --- Attachment: CASSANDRA-1838-v2.patch Add ability to set TTL on columns in cassandra-cli -- Key: CASSANDRA-1838 URL: https://issues.apache.org/jira/browse/CASSANDRA-1838 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.7.0 rc 1 Environment: Ubuntu 10.04 64bit Reporter: Eric Tamme Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.1 Attachments: CASSANDRA-1838-v2.patch, CASSANDRA-1838.patch Currently the cassandra-cli does not have any mechanism to set the ttl attribute of a column. This would be a useful ability to have when working with the cli tool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1838) Add ability to set TTL on columns in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1838: --- Attachment: (was: CASSANDRA-1838-v2.patch) Add ability to set TTL on columns in cassandra-cli -- Key: CASSANDRA-1838 URL: https://issues.apache.org/jira/browse/CASSANDRA-1838 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.7.0 rc 1 Environment: Ubuntu 10.04 64bit Reporter: Eric Tamme Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.1 Attachments: CASSANDRA-1838.patch Currently the cassandra-cli does not have any mechanism to set the ttl attribute of a column. This would be a useful ability to have when working with the cli tool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1838) Add ability to set TTL on columns in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1838: --- Attachment: CASSANDRA-1838-v2.patch GET, LIST will output 'TTL' if set. Add ability to set TTL on columns in cassandra-cli -- Key: CASSANDRA-1838 URL: https://issues.apache.org/jira/browse/CASSANDRA-1838 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.7.0 rc 1 Environment: Ubuntu 10.04 64bit Reporter: Eric Tamme Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.1 Attachments: CASSANDRA-1838-v2.patch, CASSANDRA-1838.patch Currently the cassandra-cli does not have any mechanism to set the ttl attribute of a column. This would be a useful ability to have when working with the cli tool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1840) nodetool move caused the moved node to drop itself from 'nodetool ring' output; others think it's 'joining'
[ https://issues.apache.org/jira/browse/CASSANDRA-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1840. --- Resolution: Duplicate believe this was fixed in CASSANDRA-1829 nodetool move caused the moved node to drop itself from 'nodetool ring' output; others think it's 'joining' --- Key: CASSANDRA-1840 URL: https://issues.apache.org/jira/browse/CASSANDRA-1840 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Priority: Minor I have a test cluster with three nodes on a very recent 0.7 (last few days branch). It has very little data in it (so maybe timing can be an issue given how fast operations complete). It was otherwise healthy; nodetool ring was consistent on all nodes and I had just run some compactions and 'repair' commands on all nodes repeatedly. I had a single client doing some reads/writes of single columns; nothing extreme (low load). When I did a 'nodetool move' the node exited the ring, stopped responding to thrift RPC, entered the ring again, and started accepting RPC requests via thrift. It reports in the log that it is joined. However, at this point 'nodetool ring' on the node I moved does *not* show its own location in the ring, and other nodes show it as 'joining' (with the new token, not the old token). I will include nodetool ring output and log output below. The situation was un-wedged by restarting the node that I had moved. After it started and a few seconds passed, nodetool ring looked correct on the node in question and other nodes now reported it as 'up' rather than 'joining'. Moved node said post-move (.61 in the below pastes is the node that I moved): Address Status State LoadOwnsToken 110288156320304836825416347816186393502 78.31.15.204Up Normal 224.34 KB 61.44% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 And the other two: Address Status State LoadOwnsToken 164957594472845753490452447750528540018 78.31.15.204Up Normal 224.34 KB 29.31% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 193.182.3.61Up Joining 194.76 KB 32.13% 164957594472845753490452447750528540018 Address Status State LoadOwnsToken 164957594472845753490452447750528540018 78.31.15.204Up Normal 224.34 KB 29.31% 44678687293344048155696022135861768368 193.182.3.229 Up Normal 251.84 KB 38.56% 110288156320304836825416347816186393502 193.182.3.61Up Joining 194.76 KB 32.13% 164957594472845753490452447750528540018 I'll try reproducing a few times, and also merge latest 0.7. Here is some system log output from the node that got moved; it looks good to me: INFO [RMI TCP Connection(32)-193.182.3.61] 2010-12-10 09:38:17,560 StorageService.java (line 455) Leaving: sleeping 3 ms for pending range setup INFO [RMI TCP Connection(32)-193.182.3.61] 2010-12-10 09:38:47,564 StorageService.java (line 455) Leaving: streaming data to other nodes INFO [StreamStage:1] 2010-12-10 09:38:47,566 StreamOut.java (line 75) Beginning transfer to /78.31.15.204 INFO [StreamStage:1] 2010-12-10 09:38:47,566 StreamOut.java (line 98) Flushing memtables for KeyspaceSlask... INFO [StreamStage:1] 2010-12-10 09:38:47,567 ColumnFamilyStore.java (line 639) switching in a fresh Memtable for KeyValue at CommitLogContext(file='/var/lib/spotify-cassandra/slask/commitlog/CommitLog-1291973418600.log', position=2573610) INFO [StreamStage:1] 2010-12-10 09:38:47,567 ColumnFamilyStore.java (line 943) Enqueuing flush of memtable-keyva...@1131602880(370711 bytes, 5533 operations) INFO [FlushWriter:1] 2010-12-10 09:38:47,567 Memtable.java (line 155) Writing memtable-keyva...@1131602880(370711 bytes, 5533 operations) INFO [FlushWriter:1] 2010-12-10 09:38:47,599 Memtable.java (line 162) Completed flushing /var/lib/spotify-cassandra/slask/data/KeyspaceSlask/KeyValue-e-68-Data.db (15042 bytes) INFO [StreamStage:1] 2010-12-10 09:38:47,601 StreamOut.java (line 171) Stream context metadata [/var/lib/spotify-cassandra/slask/data/KeyspaceSlask/KeyValue-e-67-Data.db/(0,10094)
[Cassandra Wiki] Update of ThomasBoose/EERD model compon ents to Cassandra Column family's by ThomasBoose
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ThomasBoose/EERD model components to Cassandra Column family's page has
been changed by ThomasBoose.
http://wiki.apache.org/cassandra/ThomasBoose/EERD%20model%20components%20to%20Cassandra%20Column%20family%27s
--
New page:
##master-page:HomepageReadWritePageTemplate
##master-date:Unknown-Date
#format wiki
#language en
= A way to implement EERD components in Cassandra =
== Intro ==
This page describes model tranformations from EERD concepts into Cassandra
ColumnFamily concepts. All input is welcome.
== DBMS layer ==
At several spots in this document you wil find suggestions to implement trivial
DBMS functionality by hand. At this stage, I would suggest to programmers to
implement at least 4 tiers when using cassandra as a backend server. One would
be the database layer by cassandra itself, One would be a tier implementing
DBMS rules, another for business rules finishing with an application tier.
In this DBMS tier functions should be available for keeping data consistend
based on datarules and it would throw exceptions when indexes are changed or
orders are given to delete key's agains DBMS rules.
If this is not yet making sence, read on.
== Indexing ==
In order to add an index to a column, other then the columnfamily's key, we
should to create a second columnfamily. Every insert, which can be either an
insert or update in cassandra, on the original columnfamily we will update the
corresponding index.
Think of a columnfamily cf_Person (examples in Python using pycassa)
cf_Person.insert('234', {'name':'Karel','City:'Haarlem'})
cfi_Person_City.insert (Haarlem', {'234':''})
This way a hash will be created containing columns for every person's key that
lives in a specific City. The ColumnFamily architecture of Cassandra can store
a unlimited number of columns for each key. This meens that when deleting a
person it reference in the cfi_Person_City index should be removed first. When
updating a person, maybe moving to anothor City, we have to remove the element
from the cfi_Person_City first and then store it with the corresponding new
City.
== Relations ==
=== 1 on 1 ===
Typicly you'll find three kinds of 1 on 1 relations in a relational model. I
will address them one at a time.
Equal elements
Sometimes all the elements are part of both collections on either side of the
relationship. The reasons these collections are moddeled seperately are most
often based on security issues or functional differences. One solution in a
Cassandra database would be the same as you would implement such a relation in
an RDBMS. Simply by sharing the same key in both columnfamilies. Inserting a
key in one of these columnfamily's would insert the same in the other and vise
versa. Updating an existing key in either columnfamily would not result in any
change in the other. Deleting a key from one columnfamily will result in
deleting the same key in the other family as well, providing this would be
allowed.
''I'm not sure to what detaillevel security rules can apply in a Cassandra
database. At least I know that one can creat logins per cluster.''
If it gets necessary to use different keys for both collections, sometimes it
is not up to one designer to select both keys, although the number of element
are equal and they are related one on one, in a relational model the designer
gets to select either key to insert into the other collection with an unique
and foreign key constraint.
In Cassandra modeling you are forced to either croslink both key's, So you
design both key's foreign in both columnfamily's. Or you create a third
columnfamily in which you store both keys preceded by a token to which
columfamily you are refering. Lets focus on the first option. Say we hand out
phones to our employees and we agree that every employee will always have one
phone. and phones that are not used are not stored in our columnfamily. The
phone has a phonenumber as key where the employee has a socialsecurity number.
In order to know which number to dial when looking for employee X and who is
calling giving a specific phonenumber we need to store both keys foreign in
both columnfamily's.
-- CF_Employee -
| | name | phone | salary |
| 123-12-1234 |John | 0555-123456| 10.000 |
| | name | phone | salary |
| 321-21-4321 |Jane | 0555-654321| 12.000 |
-- CF_Phone ---
| | employee | credit |
| 0555-123456 | 123-12-1234 | 10 |
---
| | employee | credit |
| 0555-654321 | 321-21-4321 | 5 |
---
Using a static columnname and requiring input in
[Cassandra Wiki] Trivial Update of ThomasBoose/EERD mode l components to Cassandra Column family's by ThomasBoose
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ThomasBoose/EERD model components to Cassandra Column family's page has
been changed by ThomasBoose.
http://wiki.apache.org/cassandra/ThomasBoose/EERD%20model%20components%20to%20Cassandra%20Column%20family%27s?action=diffrev1=1rev2=2
--
This page describes model tranformations from EERD concepts into Cassandra
ColumnFamily concepts. All input is welcome.
== DBMS layer ==
- At several spots in this document you wil find suggestions to implement
trivial DBMS functionality by hand. At this stage, I would suggest to
programmers to implement at least 4 tiers when using cassandra as a backend
server. One would be the database layer by cassandra itself, One would be a
tier implementing DBMS rules, another for business rules finishing with an
application tier.
+ At several spots in this document you wil find suggestions to implement
trivial DBMS functionality by hand. At this stage, I would suggest to
programmers to implement at least 4 tiers when using Cassandra as a backend
server. One would be the database layer by cassandra itself, One would be a
tier implementing DBMS rules, another for business rules finishing with an
application tier.
In this DBMS tier functions should be available for keeping data consistend
based on datarules and it would throw exceptions when indexes are changed or
orders are given to delete key's agains DBMS rules.
If this is not yet making sence, read on.
== Indexing ==
- In order to add an index to a column, other then the columnfamily's key, we
should to create a second columnfamily. Every insert, which can be either an
insert or update in cassandra, on the original columnfamily we will update the
corresponding index.
+ In order to add an index to a column, other then the ColumnFamily key, we
should to create a second ColumnFamily. Every insert, which can be either an
insert or update in Cassandra, on the original columnfamily we will update the
corresponding index.
- Think of a columnfamily cf_Person (examples in Python using pycassa)
+ Think of a ColumnFamily cf_Person (examples in Python using pycassa)
+ {{{
cf_Person.insert('234', {'name':'Karel','City:'Haarlem'})
- cfi_Person_City.insert (Haarlem', {'234':''})
+ cfi_Person_City.insert ('Haarlem', {'234':''})
-
+ }}}
- This way a hash will be created containing columns for every person's key
that lives in a specific City. The ColumnFamily architecture of Cassandra can
store a unlimited number of columns for each key. This meens that when deleting
a person it reference in the cfi_Person_City index should be removed first.
When updating a person, maybe moving to anothor City, we have to remove the
element from the cfi_Person_City first and then store it with the corresponding
new City.
+ This way a hash will be created containing columns for every person's key
that lives in a specific City. The ColumnFamily architecture of Cassandra can
store a unlimited number of columns for each key. This meens that when deleting
a person it's reference in the cfi_Person_City index should be removed first.
When updating a person, maybe moving to anothor City, we have to remove the
element from the cfi_Person_City first and then store it with the corresponding
new City.'' ''
== Relations ==
=== 1 on 1 ===
Typicly you'll find three kinds of 1 on 1 relations in a relational model. I
will address them one at a time.
Equal elements
- Sometimes all the elements are part of both collections on either side of the
relationship. The reasons these collections are moddeled seperately are most
often based on security issues or functional differences. One solution in a
Cassandra database would be the same as you would implement such a relation in
an RDBMS. Simply by sharing the same key in both columnfamilies. Inserting a
key in one of these columnfamily's would insert the same in the other and vise
versa. Updating an existing key in either columnfamily would not result in any
change in the other. Deleting a key from one columnfamily will result in
deleting the same key in the other family as well, providing this would be
allowed.
+ Sometimes all the elements are part of both collections on either side of the
relationship. The reasons these collections are moddeled seperately are most
often based on security issues or functional differences. One solution in a
Cassandra database would be the same as you would implement such a relation in
an RDBMS. Simply by sharing the same key in both ColumnFamily'ss. Inserting a
key in one of these ColumnFamily's would insert the same in the other and vise
versa. Updating an existing key in either ColumnFamily would not result in any
change in the other. Deleting a key from one ColumnFamily will result in
deleting the same key in the other family as well,
[Cassandra Wiki] Trivial Update of ThomasBoose/EERD mode l components to Cassandra Column family's by ThomasBoose
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ThomasBoose/EERD model components to Cassandra Column family's page has been changed by ThomasBoose. http://wiki.apache.org/cassandra/ThomasBoose/EERD%20model%20components%20to%20Cassandra%20Column%20family%27s?action=diffrev1=2rev2=3 -- Typicly you'll find three kinds of 1 on 1 relations in a relational model. I will address them one at a time. Equal elements - Sometimes all the elements are part of both collections on either side of the relationship. The reasons these collections are moddeled seperately are most often based on security issues or functional differences. One solution in a Cassandra database would be the same as you would implement such a relation in an RDBMS. Simply by sharing the same key in both ColumnFamily'ss. Inserting a key in one of these ColumnFamily's would insert the same in the other and vise versa. Updating an existing key in either ColumnFamily would not result in any change in the other. Deleting a key from one ColumnFamily will result in deleting the same key in the other family as well, providing this would be allowed. + Sometimes all the elements are part of both collections on either side of the relationship. The reasons these collections are moddeled seperately are most often based on security issues or functional differences. One solution in a Cassandra database would be the same as you would implement such a relation in an RDBMS. Simply by sharing the same key in both ColumnFamily's. Inserting a key in one of these ColumnFamily's would insert the same in the other and vise versa. Updating an existing key in either ColumnFamily would not result in any change in the other. Deleting a key from one ColumnFamily will result in deleting the same key in the other family as well, providing this would be allowed. ''I'm not sure to what detaillevel security rules can apply in a Cassandra database. At least I know that one can creat logins per cluster.'' - If it gets necessary to use different keys for both collections, sometimes it is not up to one designer to select both keys, although the number of element are equal and they are related one on one, in a relational model the designer gets to select either key to insert into the other collection with an unique and foreign key constraint. + If it is necessary to use different keys for both collections, sometimes it is not up to one designer to select both keys, although the number of element are equal and they are related one on one, in a relational model the designer gets to select either key to insert into the other collection with an unique and foreign key constraint. - In Cassandra modeling you are forced to either croslink both key's, So you design both key's foreign in both columnfamily's. Or you create a third columnfamily in which you store both keys preceded by a token to which columfamily you are refering. Lets focus on the first option. Say we hand out phones to our employees and we agree that every employee will always have one phone. and phones that are not used are not stored in our columnfamily. The phone has a phonenumber as key where the employee has a socialsecurity number. In order to know which number to dial when looking for employee X and who is calling giving a specific phonenumber we need to store both keys foreign in both columnfamily's. + In Cassandra modeling you are forced to either croslink both key's, So you'd design both key's foreign in both ColumnFamily's. Or you create a third ColumnFamily in which you store both keys preceded by a token to which columfamily you are refering. Lets focus on the first option. Say we hand out phones to our employees and we agree that every employee will always have one phone. and phones that are not used are not stored in our database. The phone has a phonenumber as key where the employee has a social security number. In order to know which number to dial when looking for employee X and who is calling giving a specific phonenumber we need to store both keys foreign in both ColumnFamily's. - -- CF_Employee - - | | name | phone | salary | | 123-12-1234 |John | 0555-123456| 10.000 | + ||tablewidth=400px'''CF_Employee'''|| + |||2123-12-1234||name||phone||salary|| + ||John||0555-123456||10.000|| + |||2321-21-4321||name||phone||salary|| + ||Jane||0555-654321||12.000|| - - | | name | phone | salary | - * | 321-21-4321 |Jane | 0555-654321| 12.000 | + ||tablewidth=400px tablealign=left'''CF_Phone'''|| + |||20555-123456||employee||credit|| + ||123-12-1234||10|| + |||20555-654321||employee||credit|| + ||321-21-4321||5|| - - -- CF_Phone - - * | | employee | credit | - | 0555-123456 | 123-12-1234 | 10 | - * - - * |
[jira] Commented: (CASSANDRA-1083) Improvement to CompactionManger's submitMinorIfNeeded
[
https://issues.apache.org/jira/browse/CASSANDRA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970189#action_12970189
]
Jonathan Ellis commented on CASSANDRA-1083:
---
I think this approach wastes a lot more effort than the current system, because
once it has been going a while you see this:
{code}
1 1 1 1 121 125 125 125 125 125 125 125
Compacting (ages): 64 3 2 1 0
125 125 125 125 125 125 125 125
{code}
in other words, each time we do a compaction, the common case is for it to
compact the most recent small ones with a large one, meaning 95% of the work
done is just re-copying the large.
Improvement to CompactionManger's submitMinorIfNeeded
-
Key: CASSANDRA-1083
URL: https://issues.apache.org/jira/browse/CASSANDRA-1083
Project: Cassandra
Issue Type: Improvement
Reporter: Ryan King
Assignee: Tyler Hobbs
Priority: Minor
Fix For: 0.7.1
Attachments: 1083-configurable-compaction-thresholds.patch,
compaction_simulation.rb, compaction_simulation.rb
We've discovered that we are unable to tune compaction the way we want for
our production cluster. I think the current algorithm doesn't do this as well
as it could, since it doesn't sort the sstables by size before doing the
bucketing, which means the tuning parameters have unpredictable results.
I looked at CASSANDRA-792, but it seems like overkill. Here's an alternative
proposal:
config operations:
minimumCompactionThreshold
maximumCompactionThreshold
targetSSTableCount
The first two would mean what they currently mean: the bounds on how many
sstables to compact in one compaction operation. The 3rd is a target for how
many SSTables you'd like to have.
Pseudo code algorithm for determining whether or not to do a minor compaction:
{noformat}
if sstables.length + minimumCompactionThreshold -1 targetSSTableCount
sort sstables from smallest to largest
compact the up to maximumCompactionThreshold smallest tables
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1838) Add ability to set TTL on columns in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970194#action_12970194 ] Sylvain Lebresne commented on CASSANDRA-1838: - +1 Add ability to set TTL on columns in cassandra-cli -- Key: CASSANDRA-1838 URL: https://issues.apache.org/jira/browse/CASSANDRA-1838 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.7.0 rc 1 Environment: Ubuntu 10.04 64bit Reporter: Eric Tamme Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.1 Attachments: CASSANDRA-1838-v2.patch, CASSANDRA-1838.patch Currently the cassandra-cli does not have any mechanism to set the ttl attribute of a column. This would be a useful ability to have when working with the cli tool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1083) Improvement to CompactionManger's submitMinorIfNeeded
[
https://issues.apache.org/jira/browse/CASSANDRA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1083:
--
Attachment: 1083-sort.txt
bq. [compaction] doesn't sort the sstables by size before doing the bucketing,
which means the tuning parameters have unpredictable results
patch attached to fix this
Improvement to CompactionManger's submitMinorIfNeeded
-
Key: CASSANDRA-1083
URL: https://issues.apache.org/jira/browse/CASSANDRA-1083
Project: Cassandra
Issue Type: Improvement
Reporter: Ryan King
Assignee: Tyler Hobbs
Priority: Minor
Fix For: 0.7.1
Attachments: 1083-configurable-compaction-thresholds.patch,
1083-sort.txt, compaction_simulation.rb, compaction_simulation.rb
We've discovered that we are unable to tune compaction the way we want for
our production cluster. I think the current algorithm doesn't do this as well
as it could, since it doesn't sort the sstables by size before doing the
bucketing, which means the tuning parameters have unpredictable results.
I looked at CASSANDRA-792, but it seems like overkill. Here's an alternative
proposal:
config operations:
minimumCompactionThreshold
maximumCompactionThreshold
targetSSTableCount
The first two would mean what they currently mean: the bounds on how many
sstables to compact in one compaction operation. The 3rd is a target for how
many SSTables you'd like to have.
Pseudo code algorithm for determining whether or not to do a minor compaction:
{noformat}
if sstables.length + minimumCompactionThreshold -1 targetSSTableCount
sort sstables from smallest to largest
compact the up to maximumCompactionThreshold smallest tables
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Cassandra Wiki] Update of ThomasBoose/EERD model compon ents to Cassandra Column family's by ThomasBoose
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ThomasBoose/EERD model components to Cassandra Column family's page has been changed by ThomasBoose. http://wiki.apache.org/cassandra/ThomasBoose/EERD%20model%20components%20to%20Cassandra%20Column%20family%27s?action=diffrev1=3rev2=4 -- If it is necessary to use different keys for both collections, sometimes it is not up to one designer to select both keys, although the number of element are equal and they are related one on one, in a relational model the designer gets to select either key to insert into the other collection with an unique and foreign key constraint. In Cassandra modeling you are forced to either croslink both key's, So you'd design both key's foreign in both ColumnFamily's. Or you create a third ColumnFamily in which you store both keys preceded by a token to which columfamily you are refering. Lets focus on the first option. Say we hand out phones to our employees and we agree that every employee will always have one phone. and phones that are not used are not stored in our database. The phone has a phonenumber as key where the employee has a social security number. In order to know which number to dial when looking for employee X and who is calling giving a specific phonenumber we need to store both keys foreign in both ColumnFamily's. - - - ||tablewidth=400px'''CF_Employee'''|| + tablewidth=400px'''CF_Employee''' || - |||2123-12-1234||name||phone||salary|| + ||style=text-align: center; |2123-12-1234 ||name ||phone ||salary || - ||John||0555-123456||10.000|| + ||John ||0555-123456 ||10.000 || - |||2321-21-4321||name||phone||salary|| + ||style=text-align: center; |2321-21-4321 ||name ||phone ||salary || - ||Jane||0555-654321||12.000|| + ||Jane ||0555-654321 ||12.000 || - - - ||tablewidth=400px tablealign=left'''CF_Phone'''|| - |||20555-123456||employee||credit|| - ||123-12-1234||10|| - |||20555-654321||employee||credit|| - ||321-21-4321||5|| - + ||tablewidth=400px tablestyle=text-align: left;style=text-align: center;'''CF_Phone''' || + ||style=text-align: center; |20555-123456 ||employee ||credit || + ||123-12-1234 ||10 || + ||style=text-align: center; |20555-654321 ||employee ||credit || + ||321-21-4321 ||5 || @@ -71, +66 @@ raise error or delete specified employee }}} Subset elements - '' '' + One on one relationships with one collection being smaller, in fact being a subset of the other collections in relational systems are solved by adding the key of the larger collection as foreign key to the smaler one. Preferably one uses the same key values as decribed above. This way we prevent null values that are not strictly indicating an unknown value. Null value's should only meen We know there is a value but the value is unknown as we've all learned in school. + As stated we prefer the foreign key to be the same value as the key from the superset ColumnFamily. In every other case we'll have to introduce logic to keep the relation cosistent. In any case you have to enforce the existance of all keys in the subset in the superset. Logic must also be provided when deleting elements from the superset with respect to the related element in the subset. + + Overlap + The easiest one on one relation to implement is the one in which elements in both collections do not need to be in the other but might. If at all possible create one big super ColumnFamily that collects all elements from both collections, even if there is no corresponding attribute (column). If absolutly neccessary you can provide keys from either ColumnFamily if the values are not the same but one on one related. See above for contraint considerations. + + === 1 to Many === + In one to many relationships we add the key from the one side foreign to the many side. So if we're modelinng students studing at only one school-unit at a time we would add the unit's key to the student as foreign. Considering that no foreign key logic is provided you will have to write your own code to enforce consistancy in unit's existing when the unit attribute of a student is set and defining behaviour when deleting a unit. Cosiddering the fact that this kind of relation is very common one could best create the logic for this at a seperate DBMS tier. + + Every student has only one school-unit so we enforce one static name of a column that will reference this unit. for instance this column in the cf_Student columnfamily is called school-unit. In a cassandra database this is not sufficient to retrieve all student within this unit. One could find answers to questions like these but it would require quite a lot of processing power. If a ColumnFamily, the cf_School_unit family in this case, has only one of these relations, then one could chose to add all student
[jira] Created: (CASSANDRA-1841) cassandra-cli formatted help width
cassandra-cli formatted help width -- Key: CASSANDRA-1841 URL: https://issues.apache.org/jira/browse/CASSANDRA-1841 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.0 rc 2 Reporter: Eric Evans Priority: Trivial Fix For: 0.7.0 Most of cassandra-cli's help output justifies to 81 chars, just enough to cause line wrap on most default sized terminals. It would improve appearance here if one character of the separating white space was removed so that it justified at 80 chars. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Cassandra Wiki] Trivial Update of ThomasBoose by Tho masBoose
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ThomasBoose page has been changed by ThomasBoose.
http://wiki.apache.org/cassandra/ThomasBoose?action=diffrev1=1rev2=2
--
== Thomas Boose ==
Email: MailTo(thomas AT boose DOT nl)
{{http://a0.twimg.com/profile_images/196967692/Thomas_reasonably_small.jpg}}
- Hi, I'm contributing to this wiki as part of a assignment by my university.
The asignment is to develop, design, build and implement a messaging system's
database backend for realtime, location based content provided by schools,
company's and individuals aim't at intrestgroups.
+ Hi, I'm contributing to this wiki as part of a assignment by my university.
The asignment is to develop, design, build and implement a messaging system's
database backend for realtime, location based content provided by schools,
company's and individuals aimed at intrestgroups.
- We have chosen cassandra for storage and now our task is to convert a
relational model into Cassandra columnfamily's. Therefore I'd like to create a
page describing how to implement specific EERD modeling parts to Cassandra.
I've read that not everybody supports this idea but I'd like to try it anyway.
+ We have chosen Cassandra for storage and now our task is to convert a
relational model into Cassandra ColumnFamily's. Therefore I'd like to create a
page [[EERD model components to Cassandra Column family's|describing how to
implement specific EERD modeling parts to Cassandra]]. I've read that not
everybody supports this idea but I'd like to try it anyway.
- Comments and sugestions are alway's welcome. Language improvevents are
appreciated as my native tonque is not english.
+ Comments and sugestions are alway's welcome. Language improvements are
appreciated as my native tonque is not english.
CategoryHomepage
[Cassandra Wiki] Trivial Update of ThomasBoose by Tho masBoose
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ThomasBoose page has been changed by ThomasBoose. http://wiki.apache.org/cassandra/ThomasBoose?action=diffrev1=2rev2=3 -- Hi, I'm contributing to this wiki as part of a assignment by my university. The asignment is to develop, design, build and implement a messaging system's database backend for realtime, location based content provided by schools, company's and individuals aimed at intrestgroups. - We have chosen Cassandra for storage and now our task is to convert a relational model into Cassandra ColumnFamily's. Therefore I'd like to create a page [[EERD model components to Cassandra Column family's|describing how to implement specific EERD modeling parts to Cassandra]]. I've read that not everybody supports this idea but I'd like to try it anyway. + We have chosen Cassandra for storage and now our task is to convert a relational model into Cassandra ColumnFamily's. Therefore I'd like to create a page [[ThomasBoose/EERD model components to Cassandra Column family's|describing how to implement specific EERD modeling parts to Cassandra]]. I've read that not everybody supports this idea but I'd like to try it anyway. Comments and sugestions are alway's welcome. Language improvements are appreciated as my native tonque is not english.
svn commit: r1044422 - in /cassandra/branches/cassandra-0.7: ./ src/java/org/apache/cassandra/cli/ test/unit/org/apache/cassandra/cli/
Author: jbellis
Date: Fri Dec 10 16:29:37 2010
New Revision: 1044422
URL: http://svn.apache.org/viewvc?rev=1044422view=rev
Log:
add TTL support to CLI
patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-1838
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/Cli.g
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliUserHelp.java
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/cli/CliTest.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1044422r1=1044421r2=1044422view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Fri Dec 10 16:29:37 2010
@@ -4,6 +4,7 @@ dev
* infer org.apache.cassandra.locator for replication strategy classes
when not otherwise specified
* validation that generates less garbage (CASSANDRA-1814)
+ * add TTL support to CLI (CASSANDRA-1838)
0.7.0-rc2
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/Cli.g
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/Cli.g?rev=1044422r1=1044421r2=1044422view=diff
==
--- cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/Cli.g
(original)
+++ cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/Cli.g
Fri Dec 10 16:29:37 2010
@@ -240,8 +240,8 @@ typeIdentifier
;
setStatement
-: SET columnFamilyExpr '=' value
-- ^(NODE_THRIFT_SET columnFamilyExpr value)
+: SET columnFamilyExpr '=' objectValue=value (WITH TTL '=' ttlValue=value)?
+- ^(NODE_THRIFT_SET columnFamilyExpr $objectValue ( $ttlValue )?)
;
countStatement
@@ -525,6 +525,7 @@ LIST: 'LIST';
LIMIT: 'LIMIT';
TRUNCATE: 'TRUNCATE';
ASSUME: 'ASSUME';
+TTL:'TTL';
IP_ADDRESS
: IntegerLiteral '.' IntegerLiteral '.' IntegerLiteral '.' IntegerLiteral
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java?rev=1044422r1=1044421r2=1044422view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
Fri Dec 10 16:29:37 2010
@@ -319,8 +319,9 @@ public class CliClient extends CliUserHe
for (Column col : superColumn.getColumns())
{
validator = getValidatorForValue(cfDef, col.getName());
-sessionState.out.printf(%n (column=%s, value=%s,
timestamp=%d), formatSubcolumnName(keyspace, columnFamily, col),
-validator.getString(col.value),
col.timestamp);
+sessionState.out.printf(%n (column=%s, value=%s,
timestamp=%d%s), formatSubcolumnName(keyspace, columnFamily, col),
+
validator.getString(col.value), col.timestamp,
+col.isSetTtl() ?
String.format(, ttl=%d, col.getTtl()) : );
}
sessionState.out.println());
@@ -329,8 +330,9 @@ public class CliClient extends CliUserHe
{
Column column = cosc.column;
validator = getValidatorForValue(cfDef, column.getName());
-sessionState.out.printf(= (column=%s, value=%s,
timestamp=%d)%n, formatColumnName(keyspace, columnFamily, column),
-validator.getString(column.value),
column.timestamp);
+sessionState.out.printf(= (column=%s, value=%s,
timestamp=%d%s)%n, formatColumnName(keyspace, columnFamily, column),
+
validator.getString(column.value), column.timestamp,
+column.isSetTtl() ?
String.format(, ttl=%d, column.getTtl()) : );
}
}
@@ -453,8 +455,9 @@ public class CliClient extends CliUserHe
}
// print results
-sessionState.out.printf(= (column=%s, value=%s, timestamp=%d)%n,
-formatColumnName(keySpace, columnFamily,
column), valueAsString, column.timestamp);
+sessionState.out.printf(= (column=%s, value=%s, timestamp=%d%s)%n,
+formatColumnName(keySpace, columnFamily,
[jira] Commented: (CASSANDRA-1408) nodetool drain attempts to delete a deleted file
[
https://issues.apache.org/jira/browse/CASSANDRA-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970221#action_12970221
]
Jonathan Ellis commented on CASSANDRA-1408:
---
+1
nodetool drain attempts to delete a deleted file
Key: CASSANDRA-1408
URL: https://issues.apache.org/jira/browse/CASSANDRA-1408
Project: Cassandra
Issue Type: Bug
Environment: sun-jdk-1.6/Ubuntu 10.04
Reporter: Jon Hermes
Assignee: Brandon Williams
Priority: Minor
Fix For: 0.6.9, 0.7 beta 2
Attachments: 1408-0.6.txt, 1408.txt
Running `nodetool drain` presented me with a pretty stack-trace.
The drain itself finished successfully and nothing showed up in the
system.log.
{noformat}
$ bin/nodetool -h 127.0.0.1 -p 8080 drain
Exception in thread main java.lang.AssertionError: attempted to delete
non-existing file CommitLog-1282166457787.log
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:40)
at
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:178)
at
org.apache.cassandra.service.StorageService.drain(StorageService.java:1653)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
at
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
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)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1044424 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/cli/CliClient.java
Author: jbellis
Date: Fri Dec 10 16:37:01 2010
New Revision: 1044424
URL: http://svn.apache.org/viewvc?rev=1044424view=rev
Log:
cli defaults to bytestype for subcomparator when creating CFS
patch by Pavel Yaskevich; reviewed by jbellis for CASSANDRA-1835
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1044424r1=1044423r2=1044424view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Fri Dec 10 16:37:01 2010
@@ -5,6 +5,8 @@ dev
when not otherwise specified
* validation that generates less garbage (CASSANDRA-1814)
* add TTL support to CLI (CASSANDRA-1838)
+ * cli defaults to bytestype for subcomparator when creating
+ column families (CASSANDRA-1835)
0.7.0-rc2
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java?rev=1044424r1=1044423r2=1044424view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
Fri Dec 10 16:37:01 2010
@@ -1544,6 +1544,13 @@ public class CliClient extends CliUserHe
private ByteBuffer subColumnNameAsBytes(String superColumn, CfDef
columnFamilyDef)
{
String comparatorClass = columnFamilyDef.subcomparator_type;
+
+if (comparatorClass == null)
+{
+sessionState.out.println(String.format(Notice: defaulting to
BytesType subcomparator for '%s', columnFamilyDef.getName()));
+comparatorClass = BytesType;
+}
+
return getBytesAccordingToType(superColumn,
getFormatTypeForColumn(comparatorClass));
}
[jira] Commented: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970225#action_12970225 ] T Jake Luciani commented on CASSANDRA-1470: --- .bq see http://chbits.blogspot.com/2010/06/lucene-and-fadvisemadvise.html for why posix_fadvise won't work [for writes] This article is talking about NOREUSE flag being a no-op but we are using DONTNEED which does work. Since the true goal of this ticket is to minimize the performance impact of compaction I'd like to try the following: At BRAF level: * use fadvise(DONTNEED) instead of direct-io for writes. This will fix the buffering problem we now see affecting write speed. * use fadvise(DONTNEED) for sstable reads to remove the need for directio flag altogether. * add a method long[] pagesInPageCache() which uses the posix mincore() function to detect the offsets of pages for this file currently in page cache. At Compaction level(a separate ticket): * 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 as well. A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/ use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1839) Keep a tombstone cache
[ https://issues.apache.org/jira/browse/CASSANDRA-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1839: -- Component/s: Core Priority: Minor (was: Major) Fix Version/s: (was: 0.7.1) note that this requires doing a full-row read on writes of row-level tombstones, otherwise there is a potential bug of assuming columns are supressed when they actually have a higher timestamp than the tombstone you are writing. i'm skeptical that this is worth doing for a single use case. Keep a tombstone cache -- Key: CASSANDRA-1839 URL: https://issues.apache.org/jira/browse/CASSANDRA-1839 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.3 Reporter: Brandon Williams Priority: Minor There is a use case in production where the pattern is read-then-delete, where most of the keys read will not exist, but be attempted many times. If the key has never existed, the bloom filter makes this operation cheap, however if the key has existed, especially if it has been overwritten many times and thus spans multiple SSTables, the merge-on-read just to end up with a tombstone can be expensive. This can be mitigated with keycache and some rowcache currently, but this can be further optimized by storing a sentinel value in the keycache indicating that it's a tombstone, which we can invalidate on new writes to the row. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970230#action_12970230 ] Jonathan Ellis commented on CASSANDRA-1470: --- bq. This article is talking about NOREUSE flag being a no-op but we are using DONTNEED which does work Peter wrote a book earlier in the ticket about DONTNEED -- it sounds like it could work but once you handle all the corner cases it may not actually be simpler than direct i/o. I'm open to giving it a try, though. bq. add a method long[] pagesInPageCache() which uses the posix mincore() function to detect the offsets of pages for this file currently in page cache bq. 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 Let's avoid growing the scope of this ticket and make a new one for the pre-heat sstables post-compaction feature. use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970232#action_12970232 ] Peter Schuller commented on CASSANDRA-1470: --- @jake: Pretty good idea to combine the two like this. It especially works if the new pages written can get intelligently pulled in (or rather not dropped). A few things: (1) In order for DONTNEED to be effective you have to fsync() (well, fdatasync on Linux()) first. This will have similar performance implications as direct I/O (see my long post earlier on in this ticket too), but at least removes the need to carefully ensure writes happen in chunks (but instead fsync() frequency will have to be considered and traded). (2) Remember that DONTNEED will affect the data globally for the system; meaning that a compaction that reads and does DONTNEED will actively active data from sstables being actively used. (Again see my longer post earlier in this issue). So you'd have to use mincore() when reading too in order to avoid evicting actively used data. (Note: Not doing so may be *worse* than current behavior, in addition to not causing an improvement, so I think this is important.) But given that those are eventually addressed it seems mincore+advise seems like a pretty good combination. One issue I can think of is that while mincore() gives you information in bulk for many pages, posix_fadvise() does not allow the equivalent. So we'd expect potentially quite a large number of posix_fadvise() calls assuming in-core data is scattered across a large file. That might be significant in some cases (e.g. if half of pages are in core, you may end up approaching a posix_fadvise() per page read). use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970240#action_12970240 ] T Jake Luciani commented on CASSANDRA-1470: --- @peter re (1) in the v12 patch we already split the buffer flush() from sync() so I would imagine it working like this but adding fadvise to the sync call. That way a number writes would be cached then fsync'd and discarded. re (2) from what I can find DONTNEED is global but it can be reset by another read (from another fh). Also, DONTNEED doesn't discard the pages instantly but just tells the kernel to mark them as ready to be thrown if it wants. So if the data truly is hot then a subsequent read on this file will keep them in the cache. I need to test and see if this is the case. If not then it would need to work like you describe. Also posix_fadvise will accept a range so you can specify a contiguous chunk. if the cached pages truly are randomly scattered then you are right. It would maybe then be better to overcommit the cache in this case? use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1842) ColumnFamilyOutputFormat only writes the first column
ColumnFamilyOutputFormat only writes the first column
-
Key: CASSANDRA-1842
URL: https://issues.apache.org/jira/browse/CASSANDRA-1842
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.7.0 rc 1
Reporter: Brandon Williams
Fix For: 0.7.0
In CASSANDRA-1774 we fixed a problem where only the last column was being
written. However, it appears that we only write the first one now. This is
easy to observe in the word count example:
{noformat}
RowKey: text2
= (column=word1, value=1, timestamp=1291666461685000)
{noformat}
is what the output for text2 looks like, but there should be another column,
word2. If the word count is run without CFOF it works correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-1842) ColumnFamilyOutputFormat only writes the first column
[
https://issues.apache.org/jira/browse/CASSANDRA-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna reassigned CASSANDRA-1842:
---
Assignee: Jeremy Hanna
ColumnFamilyOutputFormat only writes the first column
-
Key: CASSANDRA-1842
URL: https://issues.apache.org/jira/browse/CASSANDRA-1842
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.7.0 rc 1
Reporter: Brandon Williams
Assignee: Jeremy Hanna
Fix For: 0.7.0
In CASSANDRA-1774 we fixed a problem where only the last column was being
written. However, it appears that we only write the first one now. This is
easy to observe in the word count example:
{noformat}
RowKey: text2
= (column=word1, value=1, timestamp=1291666461685000)
{noformat}
is what the output for text2 looks like, but there should be another column,
word2. If the word count is run without CFOF it works correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1044450 - in /cassandra/branches/cassandra-0.6: CHANGES.txt src/java/org/apache/cassandra/db/ColumnFamilyStore.java src/java/org/apache/cassandra/service/StorageService.java
Author: brandonwilliams
Date: Fri Dec 10 17:35:14 2010
New Revision: 1044450
URL: http://svn.apache.org/viewvc?rev=1044450view=rev
Log:
correct ordering of drain operations so CL.recover is no longer necessary.
Patch by jbellis and brandonwilliams, reviewed by jbellis for CASSANDRA-1408
Modified:
cassandra/branches/cassandra-0.6/CHANGES.txt
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/service/StorageService.java
Modified: cassandra/branches/cassandra-0.6/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/CHANGES.txt?rev=1044450r1=109r2=1044450view=diff
==
--- cassandra/branches/cassandra-0.6/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.6/CHANGES.txt Fri Dec 10 17:35:14 2010
@@ -16,6 +16,8 @@
* reduce fat client timeout (CASSANDRA-1730)
* cleanup smallest CFs first to increase free temp space for larger ones
(CASSANDRA-1811)
+ * correct ordering of drain operations so CL.recover is no longer necessary
+ (CASSANDRA-1408)
0.6.8
Modified:
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/ColumnFamilyStore.java?rev=1044450r1=109r2=1044450view=diff
==
---
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
(original)
+++
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
Fri Dec 10 17:35:14 2010
@@ -71,27 +71,27 @@ public class ColumnFamilyStore implement
* For BinaryMemtable that's about all that happens. For live Memtables
there are two other things
* that switchMemtable does (which should be the only caller of
submitFlush in this case).
* First, it puts the Memtable into memtablesPendingFlush, where it stays
until the flush is complete
- * and it's been added as an SSTableReader to ssTables_. Second, it adds
an entry to commitLogUpdater
+ * and it's been added as an SSTableReader to ssTables_. Second, it adds
an entry to postFlushExecutor
* that waits for the flush to complete, then calls onMemtableFlush. This
allows multiple flushes
* to happen simultaneously on multicore systems, while still calling onMF
in the correct order,
* which is necessary for replay in case of a restart since CommitLog
assumes that when onMF is
* called, all data up to the given context has been persisted to SSTables.
*/
-private static ExecutorService flushSorter_
+private static final ExecutorService flushSorter
= new JMXEnabledThreadPoolExecutor(1,
Runtime.getRuntime().availableProcessors(),
Integer.MAX_VALUE,
TimeUnit.SECONDS,
new
LinkedBlockingQueueRunnable(Runtime.getRuntime().availableProcessors()),
new
NamedThreadFactory(FLUSH-SORTER-POOL));
-private static ExecutorService flushWriter_
+private static final ExecutorService flushWriter
= new JMXEnabledThreadPoolExecutor(1,
DatabaseDescriptor.getAllDataFileLocations().length,
Integer.MAX_VALUE,
TimeUnit.SECONDS,
new
LinkedBlockingQueueRunnable(DatabaseDescriptor.getAllDataFileLocations().length),
new
NamedThreadFactory(FLUSH-WRITER-POOL));
-private static ExecutorService commitLogUpdater_ = new
JMXEnabledThreadPoolExecutor(MEMTABLE-POST-FLUSHER);
+public static final ExecutorService postFlushExecutor = new
JMXEnabledThreadPoolExecutor(MEMTABLE-POST-FLUSHER);
private static final int KEY_RANGE_FILE_BUFFER_SIZE = 256 * 1024;
@@ -480,7 +480,7 @@ public class ColumnFamilyStore implement
memtable_ = new Memtable(this);
// a second executor that makes sure the onMemtableFlushes get
called in the right order,
// while keeping the wait-for-flush (future.get) out of anything
latency-sensitive.
-return commitLogUpdater_.submit(new WrappedRunnable()
+return postFlushExecutor.submit(new WrappedRunnable()
{
public void runMayThrow() throws InterruptedException,
IOException
{
@@ -747,7 +747,7 @@ public class ColumnFamilyStore implement
{
logger_.info(Enqueuing flush of + flushable);
final Condition
[jira] Resolved: (CASSANDRA-1408) nodetool drain attempts to delete a deleted file
[
https://issues.apache.org/jira/browse/CASSANDRA-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-1408.
-
Resolution: Fixed
Committed.
nodetool drain attempts to delete a deleted file
Key: CASSANDRA-1408
URL: https://issues.apache.org/jira/browse/CASSANDRA-1408
Project: Cassandra
Issue Type: Bug
Environment: sun-jdk-1.6/Ubuntu 10.04
Reporter: Jon Hermes
Assignee: Brandon Williams
Priority: Minor
Fix For: 0.6.9, 0.7 beta 2
Attachments: 1408-0.6.txt, 1408.txt
Running `nodetool drain` presented me with a pretty stack-trace.
The drain itself finished successfully and nothing showed up in the
system.log.
{noformat}
$ bin/nodetool -h 127.0.0.1 -p 8080 drain
Exception in thread main java.lang.AssertionError: attempted to delete
non-existing file CommitLog-1282166457787.log
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:40)
at
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:178)
at
org.apache.cassandra.service.StorageService.drain(StorageService.java:1653)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
at
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
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)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1083) Improvement to CompactionManger's submitMinorIfNeeded
[
https://issues.apache.org/jira/browse/CASSANDRA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970244#action_12970244
]
Ryan King commented on CASSANDRA-1083:
--
I agree. I think this idea is mostly a dead end because its attacking the
problem from the wrong direction.
Improvement to CompactionManger's submitMinorIfNeeded
-
Key: CASSANDRA-1083
URL: https://issues.apache.org/jira/browse/CASSANDRA-1083
Project: Cassandra
Issue Type: Improvement
Reporter: Ryan King
Assignee: Tyler Hobbs
Priority: Minor
Fix For: 0.7.1
Attachments: 1083-configurable-compaction-thresholds.patch,
1083-sort.txt, compaction_simulation.rb, compaction_simulation.rb
We've discovered that we are unable to tune compaction the way we want for
our production cluster. I think the current algorithm doesn't do this as well
as it could, since it doesn't sort the sstables by size before doing the
bucketing, which means the tuning parameters have unpredictable results.
I looked at CASSANDRA-792, but it seems like overkill. Here's an alternative
proposal:
config operations:
minimumCompactionThreshold
maximumCompactionThreshold
targetSSTableCount
The first two would mean what they currently mean: the bounds on how many
sstables to compact in one compaction operation. The 3rd is a target for how
many SSTables you'd like to have.
Pseudo code algorithm for determining whether or not to do a minor compaction:
{noformat}
if sstables.length + minimumCompactionThreshold -1 targetSSTableCount
sort sstables from smallest to largest
compact the up to maximumCompactionThreshold smallest tables
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1381) standard counters (support: incr + decr)
[ https://issues.apache.org/jira/browse/CASSANDRA-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1381. --- Resolution: Duplicate Assignee: (was: Kelvin Kakugawa) thanks standard counters (support: incr + decr) Key: CASSANDRA-1381 URL: https://issues.apache.org/jira/browse/CASSANDRA-1381 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Kelvin Kakugawa Attachments: CASSANDRA-1381.patch allow addition and subtraction. context tuple format: (node id, big-endian signed long, # of ops) reconciliation strategy: local: sum counts and # of ops remote: take counts based on highest # of ops -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970249#action_12970249 ] Peter Schuller commented on CASSANDRA-1470: --- (1) - great (2) - i'm pretty sure it will get instantly evicted. See http://lxr.free-electrons.com/source/mm/fadvise.c#L118 and http://lxr.free-electrons.com/source/mm/truncate.c#L309 (however I agree that with the mythical good enough implementation the hint would really just be that - a hint - but that can easily backfire; sometimes you want instant eviction; in reality I think that posix_fadvise() is too limited an interface and while you can imagine an implementation that does something correctly for a particular use-case, it's too limited to be generally suitable for everyone...). On posix_fadvise: Yes, I was only thinking of scattered pages as a problem. Contiguous ranges are fine and what one wants for fadvise purposes. On overcommitting: Certainly mincore+advise with fallback to overcommit would be an improvement still, but my gut feeling is that lots of real-life cases will definitely have very scattered hotness. Pretty much any use-case where row keys are spread randomly with respect to hotness (which I believe is very often the case), and each row is pretty small. I'm trying to think when one would expect it not to be pretty scattered. I suppose if using OPP and the row keys correspond directly to something which is correlated with hotness? So I guess something like time series data with OPP, or with RP and large rows. But it feels like a pretty narrow subset of use cases. It is worth noting that for truly large data sets scattering is fine since the cost of fadvise() per page read is still low since the contiguous ranges to drop will be fairly large. But unfortunately a lot of use cases, I assume, are with data that is either similar to memory size or a few factors of memory size (significantly smaller than memory is a non-issue since it's all in memory anyway with the current code). (As an aside, and this is not a serious suggestion since Cassandra isn't in the business of delivering kernel patches, but the implementation seems to iterate over individual pages anyway. So it seems that the only thing preventing a more efficient fadvise() for discontiguous ranges is the interface to the kernel, rather than an implementation problem. At least based on a very brief look...) use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970253#action_12970253 ] Peter Schuller commented on CASSANDRA-1470: --- Oh, and one more thing: Just to bring it up again since we're back to direct i/o vs. posix_fadvise(): Be aware that posix_fadvise() is not truly portable in practice even though it's POSIX. We have already established that DONTNEED is the only one implemented on Linux. On FreeBSD it doesn't seem to exist at all. Googling indicates it might exist in Solaris (but I have no idea to what extent or how it is implemented without checking thorougly). This is not necessarily a great argument against it, as long as the use of it is optional and Cassandra still runs without it, but at least something to not loose sight of. What about Windows, anyone? use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970254#action_12970254 ] T Jake Luciani commented on CASSANDRA-1470: --- re (2) just following the code it looks like it eventually hits http://lxr.free-electrons.com/source/mm/swap.c#L329 which is doing a reference count so if another file has the page cached then it should stick around (again I'll need to test) but that would be great! use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1470) use direct io for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970256#action_12970256 ] T Jake Luciani commented on CASSANDRA-1470: --- bq. Oh, and one more thing: Just to bring it up again since we're back to direct i/o vs. posix_fadvise(): Be aware that posix_fadvise() is not truly portable in practice even though it's POSIX. I think we should only really care about linux ATM, most everyone should be using this anyway for production use direct io for compaction Key: CASSANDRA-1470 URL: https://issues.apache.org/jira/browse/CASSANDRA-1470 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.1 Attachments: 1470-v2.txt, 1470.txt, CASSANDRA-1470-for-0.6.patch, CASSANDRA-1470-v10-for-0.7.patch, CASSANDRA-1470-v11-for-0.7.patch, CASSANDRA-1470-v12-0.7.patch, CASSANDRA-1470-v2.patch, CASSANDRA-1470-v3-0.7-with-LastErrorException-support.patch, CASSANDRA-1470-v4-for-0.7.patch, CASSANDRA-1470-v5-for-0.7.patch, CASSANDRA-1470-v6-for-0.7.patch, CASSANDRA-1470-v7-for-0.7.patch, CASSANDRA-1470-v8-for-0.7.patch, CASSANDRA-1470-v9-for-0.7.patch, CASSANDRA-1470.patch, use.DirectIORandomAccessFile.for.commitlog.against.1022235.patch When compaction scans through a group of sstables, it forces the data in the os buffer cache being used for hot reads, which can have a dramatic negative effect on performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1408) nodetool drain attempts to delete a deleted file
[
https://issues.apache.org/jira/browse/CASSANDRA-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970265#action_12970265
]
Hudson commented on CASSANDRA-1408:
---
Integrated in Cassandra-0.6 #22 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.6/22/])
correct ordering of drain operations so CL.recover is no longer necessary.
Patch by jbellis and brandonwilliams, reviewed by jbellis for CASSANDRA-1408
nodetool drain attempts to delete a deleted file
Key: CASSANDRA-1408
URL: https://issues.apache.org/jira/browse/CASSANDRA-1408
Project: Cassandra
Issue Type: Bug
Environment: sun-jdk-1.6/Ubuntu 10.04
Reporter: Jon Hermes
Assignee: Brandon Williams
Priority: Minor
Fix For: 0.6.9, 0.7 beta 2
Attachments: 1408-0.6.txt, 1408.txt
Running `nodetool drain` presented me with a pretty stack-trace.
The drain itself finished successfully and nothing showed up in the
system.log.
{noformat}
$ bin/nodetool -h 127.0.0.1 -p 8080 drain
Exception in thread main java.lang.AssertionError: attempted to delete
non-existing file CommitLog-1282166457787.log
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:40)
at
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:178)
at
org.apache.cassandra.service.StorageService.drain(StorageService.java:1653)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
at
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
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)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1706) CQL deletes (aka DELETE)
[
https://issues.apache.org/jira/browse/CASSANDRA-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-1706:
--
Attachment: v2-0001-CASSANDRA-1706-CQL-DELETE-w-functional-tests.txt
CQL deletes (aka DELETE)
Key: CASSANDRA-1706
URL: https://issues.apache.org/jira/browse/CASSANDRA-1706
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Fix For: 0.8
Attachments:
v1-0001-CASSANDRA-1706-CQL-DELETE-w-functional-tests.txt,
v2-0001-CASSANDRA-1706-CQL-DELETE-w-functional-tests.txt
Original Estimate: 0h
Remaining Estimate: 0h
CQL specification and implementation for data removal.
This corresponds to the following RPC methods:
* remove()
* batch_mutate() (deleting, not updating)
* truncate() (?)
My thoughts on the syntax are that it can probably closely mirror a subset of
`SELECT':
{code:SQL}
DELETE (FROM)? CF [USING CONSISTENCY.LVL] WHERE EXPRESSION
{code}
Optionally, you could support a form that makes the `WHERE' clause optional,
statements without the clause would be interpreted as a column family
truncation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1706) CQL deletes (aka DELETE)
[
https://issues.apache.org/jira/browse/CASSANDRA-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-1706:
--
Attachment: (was:
v1-0001-CASSANDRA-1706-CQL-DELETE-w-functional-tests.txt)
CQL deletes (aka DELETE)
Key: CASSANDRA-1706
URL: https://issues.apache.org/jira/browse/CASSANDRA-1706
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Fix For: 0.8
Attachments: v2-0001-CASSANDRA-1706-CQL-DELETE-w-functional-tests.txt
Original Estimate: 0h
Remaining Estimate: 0h
CQL specification and implementation for data removal.
This corresponds to the following RPC methods:
* remove()
* batch_mutate() (deleting, not updating)
* truncate() (?)
My thoughts on the syntax are that it can probably closely mirror a subset of
`SELECT':
{code:SQL}
DELETE (FROM)? CF [USING CONSISTENCY.LVL] WHERE EXPRESSION
{code}
Optionally, you could support a form that makes the `WHERE' clause optional,
statements without the clause would be interpreted as a column family
truncation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1706) CQL deletes (aka DELETE)
[
https://issues.apache.org/jira/browse/CASSANDRA-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970269#action_12970269
]
Eric Evans commented on CASSANDRA-1706:
---
The attached (updated) patch implements DELETE, and includes functional tests
and update docu.
CQL deletes (aka DELETE)
Key: CASSANDRA-1706
URL: https://issues.apache.org/jira/browse/CASSANDRA-1706
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Fix For: 0.8
Attachments: v2-0001-CASSANDRA-1706-CQL-DELETE-w-functional-tests.txt
Original Estimate: 0h
Remaining Estimate: 0h
CQL specification and implementation for data removal.
This corresponds to the following RPC methods:
* remove()
* batch_mutate() (deleting, not updating)
* truncate() (?)
My thoughts on the syntax are that it can probably closely mirror a subset of
`SELECT':
{code:SQL}
DELETE (FROM)? CF [USING CONSISTENCY.LVL] WHERE EXPRESSION
{code}
Optionally, you could support a form that makes the `WHERE' clause optional,
statements without the clause would be interpreted as a column family
truncation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Cassandra Wiki] Trivial Update of ThomasBoose/EERD mode l components to Cassandra Column family's by ThomasBoose
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ThomasBoose/EERD model components to Cassandra Column family's page has
been changed by ThomasBoose.
http://wiki.apache.org/cassandra/ThomasBoose/EERD%20model%20components%20to%20Cassandra%20Column%20family%27s?action=diffrev1=4rev2=5
--
If this is not yet making sence, read on.
== Indexing ==
- In order to add an index to a column, other then the ColumnFamily key, we
should to create a second ColumnFamily. Every insert, which can be either an
insert or update in Cassandra, on the original columnfamily we will update the
corresponding index.
+ In order to add an index to a column, other then the ColumnFamily key, we
should to create a second ColumnFamily. Every insert, which can be either an
insert or update in Cassandra, on the original ColumnFamily we will update the
corresponding index.
Think of a ColumnFamily cf_Person (examples in Python using pycassa)
@@ -38, +38 @@
If it is necessary to use different keys for both collections, sometimes it
is not up to one designer to select both keys, although the number of element
are equal and they are related one on one, in a relational model the designer
gets to select either key to insert into the other collection with an unique
and foreign key constraint.
In Cassandra modeling you are forced to either croslink both key's, So you'd
design both key's foreign in both ColumnFamily's. Or you create a third
ColumnFamily in which you store both keys preceded by a token to which
columfamily you are refering. Lets focus on the first option. Say we hand out
phones to our employees and we agree that every employee will always have one
phone. and phones that are not used are not stored in our database. The phone
has a phonenumber as key where the employee has a social security number. In
order to know which number to dial when looking for employee X and who is
calling giving a specific phonenumber we need to store both keys foreign in
both ColumnFamily's.
- tablewidth=400px'''CF_Employee''' ||
+ tablewidth=400pxstyle=text-align: center;'''CF_Employee''' ||
||style=text-align: center; |2123-12-1234 ||name ||phone ||salary ||
||John ||0555-123456 ||10.000 ||
||style=text-align: center; |2321-21-4321 ||name ||phone ||salary ||
||Jane ||0555-654321 ||12.000 ||
-
||tablewidth=400px tablestyle=text-align: left;style=text-align:
center;'''CF_Phone''' ||
@@ -55, +54 @@
- Using a static columnname and requiring input in the foreign key fields,
checking the existence of the key in the other columnfamily and processing
updates and deletes are all subject to programming in the DBMS layer. Cassandra
itself does not, and probably will not, provide foreign key logic. One could
imagine an process that makes sure the cross references stay consistend:
+ Using a static columnname and requiring input in the foreign key fields,
checking the existence of the key in the other ColumnFamily and processing
updates and deletes are all subject to programming in the DBMS layer. Cassandra
itself does not, and probably will not, provide foreign key logic. One could
imagine an process that makes sure the cross references stay consistend:
{{{
cf_Employee.insert('321-21-4321', {'name':'Jane', 'phone':'0555-654321'})
@@ -76, +75 @@
=== 1 to Many ===
In one to many relationships we add the key from the one side foreign to
the many side. So if we're modelinng students studing at only one school-unit
at a time we would add the unit's key to the student as foreign. Considering
that no foreign key logic is provided you will have to write your own code to
enforce consistancy in unit's existing when the unit attribute of a student is
set and defining behaviour when deleting a unit. Cosiddering the fact that this
kind of relation is very common one could best create the logic for this at a
seperate DBMS tier.
- Every student has only one school-unit so we enforce one static name of a
column that will reference this unit. for instance this column in the
cf_Student columnfamily is called school-unit. In a cassandra database this
is not sufficient to retrieve all student within this unit. One could find
answers to questions like these but it would require quite a lot of processing
power. If a ColumnFamily, the cf_School_unit family in this case, has only one
of these relations, then one could chose to add all student keys to that
ColumnFamily it self. I would not count on this situation persisting in future
releases of you system and therefore sugest that you'de provide seperate
ColumnFamily's for each one to many relationship that you model.
+ Every student has only one school-unit so we enforce one static name of a
column that will reference this unit. for instance this column in the
cf_Student ColumnFamily is called
[Cassandra Wiki] Trivial Update of ThomasBoose by Tho masBoose
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ThomasBoose page has been changed by ThomasBoose. http://wiki.apache.org/cassandra/ThomasBoose?action=diffrev1=3rev2=4 -- Comments and sugestions are alway's welcome. Language improvements are appreciated as my native tonque is not english. + More info on me on LinkedIn: - - CategoryHomepage + http://nl.linkedin.com/in/boose +
[jira] Commented: (CASSANDRA-1837) Deleted columns are resurrected after a flush
[
https://issues.apache.org/jira/browse/CASSANDRA-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970300#action_12970300
]
Gary Dusbabek commented on CASSANDRA-1837:
--
This is happening because of bug in the way deleted rows are [not] interpreted
in the CFS.getRangeSlice code. CFS.getColumnFamily doesn't exhibit the bug,
but the codepath is pretty different.
I've got a fix that addresses standard columns, but it breaks a few of the
nosetests for super columns. Looking into that now.
Deleted columns are resurrected after a flush
-
Key: CASSANDRA-1837
URL: https://issues.apache.org/jira/browse/CASSANDRA-1837
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0 rc 1
Reporter: Brandon Williams
Assignee: Gary Dusbabek
Priority: Blocker
Fix For: 0.7.0
Easily reproduced with the cli:
{noformat}
[defa...@unknown] create keyspace testks;
2785d67c-02df-11e0-ac09-e700f669bcfc
[defa...@unknown] use testks;
Authenticated to keyspace: testks
[defa...@testks] create column family testcf;
2fbad20d-02df-11e0-ac09-e700f669bcfc
[defa...@testks] set testcf['test']['foo'] = 'foo';
Value inserted.
[defa...@testks] set testcf['test']['bar'] = 'bar';
Value inserted.
[defa...@testks] list testcf;
Using default limit of 100
---
RowKey: test
= (column=626172, value=626172, timestamp=129182186912)
= (column=666f6f, value=666f6f, timestamp=129182185732)
1 Row Returned.
[defa...@testks] del testcf['test'];
row removed.
[defa...@testks] list testcf;
Using default limit of 100
---
RowKey: test
1 Row Returned.
{noformat}
Now flush testks and look again:
{noformat}
[defa...@testks] list testcf;
Using default limit of 100
---
RowKey: test
= (column=626172, value=626172, timestamp=129182186912)
= (column=666f6f, value=666f6f, timestamp=129182185732)
1 Row Returned.
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-1837) Deleted columns are resurrected after a flush
[
https://issues.apache.org/jira/browse/CASSANDRA-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970300#action_12970300
]
Gary Dusbabek edited comment on CASSANDRA-1837 at 12/10/10 3:11 PM:
This is happening because of bug in the way deleted rows are [not] interpreted
once they leave the memtable in the CFS.getRangeSlice code.
CFS.getColumnFamily doesn't exhibit the bug, but the codepath is pretty
different.
I've got a fix that addresses standard columns, but it breaks a few of the
nosetests for super columns. Looking into that now.
was (Author: gdusbabek):
This is happening because of bug in the way deleted rows are [not]
interpreted in the CFS.getRangeSlice code. CFS.getColumnFamily doesn't exhibit
the bug, but the codepath is pretty different.
I've got a fix that addresses standard columns, but it breaks a few of the
nosetests for super columns. Looking into that now.
Deleted columns are resurrected after a flush
-
Key: CASSANDRA-1837
URL: https://issues.apache.org/jira/browse/CASSANDRA-1837
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0 rc 1
Reporter: Brandon Williams
Assignee: Gary Dusbabek
Priority: Blocker
Fix For: 0.7.0
Easily reproduced with the cli:
{noformat}
[defa...@unknown] create keyspace testks;
2785d67c-02df-11e0-ac09-e700f669bcfc
[defa...@unknown] use testks;
Authenticated to keyspace: testks
[defa...@testks] create column family testcf;
2fbad20d-02df-11e0-ac09-e700f669bcfc
[defa...@testks] set testcf['test']['foo'] = 'foo';
Value inserted.
[defa...@testks] set testcf['test']['bar'] = 'bar';
Value inserted.
[defa...@testks] list testcf;
Using default limit of 100
---
RowKey: test
= (column=626172, value=626172, timestamp=129182186912)
= (column=666f6f, value=666f6f, timestamp=129182185732)
1 Row Returned.
[defa...@testks] del testcf['test'];
row removed.
[defa...@testks] list testcf;
Using default limit of 100
---
RowKey: test
1 Row Returned.
{noformat}
Now flush testks and look again:
{noformat}
[defa...@testks] list testcf;
Using default limit of 100
---
RowKey: test
= (column=626172, value=626172, timestamp=129182186912)
= (column=666f6f, value=666f6f, timestamp=129182185732)
1 Row Returned.
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-1654) EC2Snitch
[ https://issues.apache.org/jira/browse/CASSANDRA-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-1654: - Assignee: Brandon Williams EC2Snitch - Key: CASSANDRA-1654 URL: https://issues.apache.org/jira/browse/CASSANDRA-1654 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Brandon Williams Fix For: 0.7.1 Attachments: 1654-incomplete.txt, 1654.txt This will be a snitch extending AbstractNetworkTopologySnitch that pulls DC from instance metadata placement_availability_zone. I don't think we can get rack information so the choice is between picking something unique-per-machine to be the rack or assigning everything in the DC the same rack. Second seems easier, so let's use placement_availability_zone for rack, too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-1207) Don't write BloomFilters for skinny rows
[ https://issues.apache.org/jira/browse/CASSANDRA-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-1207: - Assignee: Brandon Williams Don't write BloomFilters for skinny rows Key: CASSANDRA-1207 URL: https://issues.apache.org/jira/browse/CASSANDRA-1207 Project: Cassandra Issue Type: Improvement Reporter: Stu Hood Assignee: Brandon Williams Priority: Minor Fix For: 0.7.1 Attachments: 0001-Return-alwaysMatchingBloomFilter-for-0-length-filter.patch, 0002-Conditionally-write-the-row-bloom-filter.patch All rows currently contain a serialized BloomFilter, regardless of size. For smaller rows, it is much more efficient in space and CPU time to not write a BloomFilter, and to eagerly perform lookups against the existing columns. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-1797) Create topology-oblivious snitch that still knows enough to prefer local reads to nonlocal
[ https://issues.apache.org/jira/browse/CASSANDRA-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-1797: - Assignee: Brandon Williams Create topology-oblivious snitch that still knows enough to prefer local reads to nonlocal -- Key: CASSANDRA-1797 URL: https://issues.apache.org/jira/browse/CASSANDRA-1797 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.7 beta 1 Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Minor Fix For: 0.7.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-1123) Allow tracing query details
[ https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-1123: - Assignee: Brandon Williams Allow tracing query details --- Key: CASSANDRA-1123 URL: https://issues.apache.org/jira/browse/CASSANDRA-1123 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Brandon Williams Fix For: 0.8 In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where latency is coming from: how long did row cache lookup take? key search in the index? merging the data from the sstables? etc. The main difference vs setting debug logging is that debug logging is too big of a hammer; by turning on the flood of logging for everyone, you actually distort the information you're looking for. This would be something you could set per-query (or more likely per connection). We don't need to be as sophisticated as the techniques discussed in the following papers but they are interesting reading: http://research.google.com/pubs/pub36356.html http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/ http://www.usenix.org/event/nsdi07/tech/fonseca.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Cassandra Wiki] Update of FAQ by DustyReagan
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The FAQ page has been changed by DustyReagan. http://wiki.apache.org/cassandra/FAQ?action=diffrev1=97rev2=98 -- == unsubscribe == - You're doing it wrong. + Send an email to user-unsubscr...@cassandra.apache.org
[jira] Commented: (CASSANDRA-1207) Don't write BloomFilters for skinny rows
[ https://issues.apache.org/jira/browse/CASSANDRA-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970327#action_12970327 ] Brandon Williams commented on CASSANDRA-1207: - I'm inclined to think specifying something in the CF definition is the better approach here. Too many of the deciding factors on where to choose the automatic limit depend on the use case involved (such as the index example, where the row is large but only sliced.) The automatic approach can help the naive user, but the more powerful user will have to constrain their model/access pattern to our threshold to gain its benefits. We could use an automatic default, but allow overriding it for more advanced cases. Don't write BloomFilters for skinny rows Key: CASSANDRA-1207 URL: https://issues.apache.org/jira/browse/CASSANDRA-1207 Project: Cassandra Issue Type: Improvement Reporter: Stu Hood Assignee: Brandon Williams Priority: Minor Fix For: 0.7.1 Attachments: 0001-Return-alwaysMatchingBloomFilter-for-0-length-filter.patch, 0002-Conditionally-write-the-row-bloom-filter.patch All rows currently contain a serialized BloomFilter, regardless of size. For smaller rows, it is much more efficient in space and CPU time to not write a BloomFilter, and to eagerly perform lookups against the existing columns. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1843) Indexes: CF MBeans for automatic indexes are never unregistered when they are deleted.
Indexes: CF MBeans for automatic indexes are never unregistered when they are
deleted.
--
Key: CASSANDRA-1843
URL: https://issues.apache.org/jira/browse/CASSANDRA-1843
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.0 rc 1
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.0 rc 2
Add, delete, and add the same index and you should get a stacktrace to this
effect:
{noformat}
java.lang.RuntimeException: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=IndexColumnFamilies,keyspace=Keyspace1,columnfamily=Standard1.616765
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:259)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:447)
at
org.apache.cassandra.db.ColumnFamilyStore.addIndex(ColumnFamilyStore.java:304)
at
org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:193)
at
org.apache.cassandra.db.migration.UpdateColumnFamily.applyModels(UpdateColumnFamily.java:80)
at org.apache.cassandra.db.migration.Migration.apply(Migration.java:171)
at
org.apache.cassandra.thrift.CassandraServer$2.call(CassandraServer.java:663)
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)
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=IndexColumnFamilies,keyspace=Keyspace1,columnfamily=Standard1.616765
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:255)
... 11 more{noformat}
CFS.reload() manages index deletion, but never unregisters the MBeans it
creates during initialization.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1044573 - /cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/service/EmbeddedCassandraServiceTest.java
Author: jbellis
Date: Sat Dec 11 06:51:11 2010
New Revision: 1044573
URL: http://svn.apache.org/viewvc?rev=1044573view=rev
Log:
ECST no longer needs to manually read cfdefs from yaml now that cleanuphelper
(via schemaloader) is
Modified:
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/service/EmbeddedCassandraServiceTest.java
Modified:
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/service/EmbeddedCassandraServiceTest.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/service/EmbeddedCassandraServiceTest.java?rev=1044573r1=1044572r2=1044573view=diff
==
---
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/service/EmbeddedCassandraServiceTest.java
(original)
+++
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/service/EmbeddedCassandraServiceTest.java
Sat Dec 11 06:51:11 2010
@@ -65,14 +65,6 @@ public class EmbeddedCassandraServiceTes
public static void setup() throws TTransportException, IOException,
InterruptedException, ConfigurationException
{
-// Manually load tables from the test configuration file.
-for (KSMetaData table : DatabaseDescriptor.readTablesFromYaml())
-{
-for (CFMetaData cfm : table.cfMetaData().values())
-CFMetaData.map(cfm);
-DatabaseDescriptor.setTableDefinition(table,
DatabaseDescriptor.getDefsVersion());
-}
-
cassandra = new EmbeddedCassandraService();
cassandra.init();
[jira] Resolved: (CASSANDRA-1783) spurious failures of o.a.c.db.NameSortTest:testNameSort100
[
https://issues.apache.org/jira/browse/CASSANDRA-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-1783.
---
Resolution: Fixed
Assignee: Jonathan Ellis
fixed in r1044570
spurious failures of o.a.c.db.NameSortTest:testNameSort100
--
Key: CASSANDRA-1783
URL: https://issues.apache.org/jira/browse/CASSANDRA-1783
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0 rc 1
Environment: Hudson, ubuntu2 (vesta.apache.org)
Reporter: Eric Evans
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.7.1
{noformat}
[junit] Cobertura: Loaded information on 961 classes.
[junit] Cobertura: Saved information on 961 classes.
[junit] Testsuite: org.apache.cassandra.db.NameSortTest
[junit] Testsuite: org.apache.cassandra.db.NameSortTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase: org.apache.cassandra.db.NameSortTest:testNameSort100:
Caused an ERROR
[junit] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit]
{noformat}
See also: https://hudson.apache.org/hudson/job/Cassandra-0.7/33/console
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1783) spurious failures of o.a.c.db.NameSortTest:testNameSort100
[
https://issues.apache.org/jira/browse/CASSANDRA-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1783:
--
Priority: Trivial (was: Minor)
Fix Version/s: (was: 0.7.1)
0.7.0
spurious failures of o.a.c.db.NameSortTest:testNameSort100
--
Key: CASSANDRA-1783
URL: https://issues.apache.org/jira/browse/CASSANDRA-1783
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0 rc 1
Environment: Hudson, ubuntu2 (vesta.apache.org)
Reporter: Eric Evans
Assignee: Jonathan Ellis
Priority: Trivial
Fix For: 0.7.0
{noformat}
[junit] Cobertura: Loaded information on 961 classes.
[junit] Cobertura: Saved information on 961 classes.
[junit] Testsuite: org.apache.cassandra.db.NameSortTest
[junit] Testsuite: org.apache.cassandra.db.NameSortTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase: org.apache.cassandra.db.NameSortTest:testNameSort100:
Caused an ERROR
[junit] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit]
{noformat}
See also: https://hudson.apache.org/hudson/job/Cassandra-0.7/33/console
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1803) fail fast in strongRead when insufficient replicas are available to satisfy ConsistencyLevel
[ https://issues.apache.org/jira/browse/CASSANDRA-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970391#action_12970391 ] Hudson commented on CASSANDRA-1803: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) fail fast in strongRead when insufficient replicas are available to satisfy ConsistencyLevel Key: CASSANDRA-1803 URL: https://issues.apache.org/jira/browse/CASSANDRA-1803 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.0 rc 2 Attachments: 1803.txt, 1803_v2.txt Currently strongRead (the patch for ConsistencyLevel 1) always sends out requests to all live replicas, even if there are not enough to satisfy the ConsistencyLevel. This is a violation of our contract w/ the client to throw UnavailableException when we know ahead of time that the request cannot be fulfilled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1770) cassandra-cli help output should mention the need for semicolons
[
https://issues.apache.org/jira/browse/CASSANDRA-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970393#action_12970393
]
Hudson commented on CASSANDRA-1770:
---
Integrated in Cassandra-0.7 #70 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/70/])
cassandra-cli help output should mention the need for semicolons
Key: CASSANDRA-1770
URL: https://issues.apache.org/jira/browse/CASSANDRA-1770
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0 rc 1
Environment: Debian squeeze with 0.7.0~rc1 package installed
Reporter: paul cannon
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.7.0 rc 2
Attachments: CASSANDRA-1770.patch
When running cassandra-cli for the first time after upgrading beta3 - rc1, I
thought it was broken, because any command I typed (?, quit, exit, use
system, etc) just printed some empty space and sat there until I killed it.
I didn't know it was a continuation prompt, or that semicolons were needed.
The startup banner message currently says:
{noformat}
Connected to: Test Cluster on localhost/9160
Welcome to cassandra CLI.
Type 'help' or '?' for help. Type 'quit' or 'exit' to quit.
{noformat}
I believe that the example commands should have semicolons after them, to let
the user know about the change.
Also, a ? by itself should probably not require a semicolon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1829) Nodetool move is broken
[ https://issues.apache.org/jira/browse/CASSANDRA-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970394#action_12970394 ] Hudson commented on CASSANDRA-1829: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) Nodetool move is broken --- Key: CASSANDRA-1829 URL: https://issues.apache.org/jira/browse/CASSANDRA-1829 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 rc 1 Reporter: Nick Bailey Assignee: Nick Bailey Priority: Blocker Fix For: 0.7.0 Attachments: 0001-Update-token-after-bootstrapping.patch The code from finishBootstrapping that finishes a move was removed. This means a move will leave a node stuck in a bootstrapping state forever. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1801) bytebuffers of column data written locally prevent GC of original thrift mutation byte[]
[ https://issues.apache.org/jira/browse/CASSANDRA-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970390#action_12970390 ] Hudson commented on CASSANDRA-1801: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) bytebuffers of column data written locally prevent GC of original thrift mutation byte[] Key: CASSANDRA-1801 URL: https://issues.apache.org/jira/browse/CASSANDRA-1801 Project: Cassandra Issue Type: Bug Affects Versions: 0.7 beta 3 Reporter: Matthew F. Dennis Assignee: T Jake Luciani Fix For: 0.7.0 rc 2 Attachments: 1801_v1.txt, 1801_v2.txt, screenie.png It appears C* isn't releasing buffers that were used during the writes of batch mutates. See attached screenshot of heap dump. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1790) Booting fails on Windows 7/Windows 2003 because of a file rename failure
[
https://issues.apache.org/jira/browse/CASSANDRA-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970395#action_12970395
]
Hudson commented on CASSANDRA-1790:
---
Integrated in Cassandra-0.7 #70 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/70/])
Booting fails on Windows 7/Windows 2003 because of a file rename failure
Key: CASSANDRA-1790
URL: https://issues.apache.org/jira/browse/CASSANDRA-1790
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0 rc 1
Environment: Windows 7 (64-bit), Windows 2003 (32-bit)
Reporter: Ramon Rockx
Assignee: Jonathan Ellis
Priority: Blocker
Fix For: 0.7.0 rc 2
Attachments: 1790.txt
Cassandra 0.7.0 rc will not boot on Windows 7 and Windows 2003 because of a
file rename failure. The logging:
{noformat}
INFO [FlushWriter:1] 2010-11-25 17:12:43,796 Memtable.java (line 155)
Writing memtable-locationi...@691789110(435 bytes, 8 operations)
ERROR [FlushWriter:1] 2010-11-25 17:12:43,993 AbstractCassandraDaemon.java
(line 90) Fatal exception in thread Thread[FlushWriter:1,5,main]
java.io.IOError: java.io.IOException: rename failed of
d:\cassandra\data\system\LocationInfo-e-1-Data.db
at
org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.java:214)
at
org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:184)
at
org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:167)
at
org.apache.cassandra.db.Memtable.writeSortedContents(Memtable.java:161)
at org.apache.cassandra.db.Memtable.access$000(Memtable.java:49)
at org.apache.cassandra.db.Memtable$1.runMayThrow(Memtable.java:174)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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:619)
Caused by: java.io.IOException: rename failed of
d:\cassandra\data\system\LocationInfo-e-1-Data.db
at
org.apache.cassandra.utils.FBUtilities.renameWithConfirm(FBUtilities.java:359)
at
org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.java:210)
... 12 more
INFO [main] 2010-11-29 09:16:36,219 AbstractCassandraDaemon.java (line 73)
Heap size: 1067253760/1067253760
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1843) Indexes: CF MBeans for automatic indexes are never unregistered when they are deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970392#action_12970392
]
Hudson commented on CASSANDRA-1843:
---
Integrated in Cassandra-0.7 #70 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/70/])
Indexes: CF MBeans for automatic indexes are never unregistered when they are
deleted.
--
Key: CASSANDRA-1843
URL: https://issues.apache.org/jira/browse/CASSANDRA-1843
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.0 rc 1
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.0
Attachments: 1843.txt
Add, delete, and add the same index and you should get a stacktrace to this
effect:
{noformat}
java.lang.RuntimeException: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=IndexColumnFamilies,keyspace=Keyspace1,columnfamily=Standard1.616765
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:259)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:447)
at
org.apache.cassandra.db.ColumnFamilyStore.addIndex(ColumnFamilyStore.java:304)
at
org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:193)
at
org.apache.cassandra.db.migration.UpdateColumnFamily.applyModels(UpdateColumnFamily.java:80)
at org.apache.cassandra.db.migration.Migration.apply(Migration.java:171)
at
org.apache.cassandra.thrift.CassandraServer$2.call(CassandraServer.java:663)
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)
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=IndexColumnFamilies,keyspace=Keyspace1,columnfamily=Standard1.616765
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:255)
... 11 more{noformat}
CFS.reload() manages index deletion, but never unregisters the MBeans it
creates during initialization.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1773) Prevent creation of column_metadata inconsistent with comparator
[
https://issues.apache.org/jira/browse/CASSANDRA-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970398#action_12970398
]
Hudson commented on CASSANDRA-1773:
---
Integrated in Cassandra-0.7 #70 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/70/])
Prevent creation of column_metadata inconsistent with comparator
Key: CASSANDRA-1773
URL: https://issues.apache.org/jira/browse/CASSANDRA-1773
Project: Cassandra
Issue Type: Improvement
Affects Versions: 0.7.0 rc 1
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.7.0 rc 2
Attachments: 1773-server-side.txt, CASSANDRA-1773.patch
{code}
create keyspace clitest with replication_factor = 1 and placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy';
use clitest;
create column family bar with column_type = 'Super' and comparator =
'TimeUUIDType' and subcomparator = 'UTF8Type';
create column family foo with column_type = 'Super' and comparator =
'TimeUUIDType' and subcomparator = 'UTF8Type' and
column_metadata=[{column_name:col1, validation_class:UTF8Type},
{column_name:col2, validation_class:UTF8Type}];
{code}
then, describe keyspace clitest will give UUIDs must be exactly 16 bytes
because it tries to run col1 through the comparator getString.
We should check that column names in metadata match the comparator when
updating metadata, and also check that the column names are sane if we update
the comparator itself.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1759) Column MetaData: Index_name should not be allowed if index_type is not set.
[ https://issues.apache.org/jira/browse/CASSANDRA-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970402#action_12970402 ] Hudson commented on CASSANDRA-1759: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) Column MetaData: Index_name should not be allowed if index_type is not set. --- Key: CASSANDRA-1759 URL: https://issues.apache.org/jira/browse/CASSANDRA-1759 Project: Cassandra Issue Type: Bug Affects Versions: 0.7 beta 1 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Trivial Fix For: 0.7.0 rc 2 Attachments: 1759-2.txt, 1759.txt Giving an indexName starts the automatic index creation process. If indexType is not also set, then that process barfs. If a name is present, a type must be also (but the reverse is not necessarily true). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1795) [patch] avoid unnecessary use of synchronized collection for non escaped local varables
[ https://issues.apache.org/jira/browse/CASSANDRA-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970403#action_12970403 ] Hudson commented on CASSANDRA-1795: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) [patch] avoid unnecessary use of synchronized collection for non escaped local varables --- Key: CASSANDRA-1795 URL: https://issues.apache.org/jira/browse/CASSANDRA-1795 Project: Cassandra Issue Type: Improvement Environment: ubuntu jdk1..6.17 ant 1.8 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 0.7.0 rc 2 Attachments: avoid_local_sync_collections.diff Original Estimate: 1h Remaining Estimate: 1h code uses a Hashtable even tho the collection is a local variable that is not escaped from the method. The synchronization is not needed, switch to HashMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1754) SSTable Import/Export doesn't support ExpiringColumns
[ https://issues.apache.org/jira/browse/CASSANDRA-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970397#action_12970397 ] Hudson commented on CASSANDRA-1754: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) SSTable Import/Export doesn't support ExpiringColumns - Key: CASSANDRA-1754 URL: https://issues.apache.org/jira/browse/CASSANDRA-1754 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.7.0 rc 2 Attachments: 0001-Support-Expiring-Columns-in-SSTableImport-Export.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1772) debian initscript sometimes mistakenly thinks it failed, gives extraneous output
[ https://issues.apache.org/jira/browse/CASSANDRA-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970396#action_12970396 ] Hudson commented on CASSANDRA-1772: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) debian initscript sometimes mistakenly thinks it failed, gives extraneous output Key: CASSANDRA-1772 URL: https://issues.apache.org/jira/browse/CASSANDRA-1772 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.7.0 rc 1 Environment: Debian Squeeze with cassandra 0.7.0~rc1 on a slicehost VM Reporter: paul cannon Assignee: paul cannon Priority: Minor Fix For: 0.7.0 rc 2 Attachments: cass-add-status.patch.txt, cass-wait-for-start.patch.txt On my test systems, which are all relatively slow VMs, the Cassandra debian initscript usually thinks it fails to start, even though the startup was successful. It appears that jsvc forks the daemon process and exits, and the initscript check for the running Cassandra service occurs before the new daemon is able to initialize itself and create its pidfile. On top of that, most invocations end up spitting out a small amount of garbage from /bin/ps, in addition to the typical Stopping Cassandra: cassandra. log messages one sees if verbose=yes in /etc/default/rcS. This is not very flattering. Finally, the initscript should provide the status command to meet current LSB spec. The functionality is mostly complete already anyway, and it can be quite useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1793) [patch] cleanup minor field usage that can be moved to static or locals
[ https://issues.apache.org/jira/browse/CASSANDRA-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970400#action_12970400 ] Hudson commented on CASSANDRA-1793: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) [patch] cleanup minor field usage that can be moved to static or locals --- Key: CASSANDRA-1793 URL: https://issues.apache.org/jira/browse/CASSANDRA-1793 Project: Cassandra Issue Type: Improvement Environment: ubuntu 10.10 jdk1.6.17 ant1.8 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 0.7.0 rc 2 Attachments: cleanup_fields.diff Original Estimate: 1h Remaining Estimate: 1h minor cleanups to move fields to statics, or locals to give the gc a small helping hand. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1809) cli executeGetWithConditions is not case-insensitive for CF names
[
https://issues.apache.org/jira/browse/CASSANDRA-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970405#action_12970405
]
Hudson commented on CASSANDRA-1809:
---
Integrated in Cassandra-0.7 #70 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/70/])
cli executeGetWithConditions is not case-insensitive for CF names
-
Key: CASSANDRA-1809
URL: https://issues.apache.org/jira/browse/CASSANDRA-1809
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0 rc 1
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.7.0 rc 2
Attachments: CASSANDRA-1809.patch
{code}
String columnFamily = statement.getChild(0).getText();
{code}
is not being normalized for case...
I tried
{code}
-String columnFamily = statement.getChild(0).getText();
+String columnFamily =
CliCompiler.getColumnFamily(statement.getChild(0),
keyspacesMap.get(keySpace).cf_defs);
{code}
but that broke it, all gets returned null (missing exception message?)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1730) Fat clients are never removed
[ https://issues.apache.org/jira/browse/CASSANDRA-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970399#action_12970399 ] Hudson commented on CASSANDRA-1730: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) Fat clients are never removed - Key: CASSANDRA-1730 URL: https://issues.apache.org/jira/browse/CASSANDRA-1730 Project: Cassandra Issue Type: Bug Affects Versions: 0.6.7 Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 0.6.9 Attachments: 1730.txt After a failed bootstrap, these lines repeat infinitely: INFO [Timer-0] 2010-11-11 01:58:32,708 Gossiper.java (line 406) FatClient /10.104.73.164 has been silent for 360ms, removing from gossip INFO [GMFD:1] 2010-11-11 01:59:03,685 Gossiper.java (line 591) Node /10.104.73.164 is now part of the cluster Changing the IP on the node but using the same token causes a conflict, requiring either a full cluster restart or changing the token. This is especially easy to run into in practice in a virtual environment such as ec2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1794) [patch] avoid map look ups in a loop by using entrySet
[ https://issues.apache.org/jira/browse/CASSANDRA-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970401#action_12970401 ] Hudson commented on CASSANDRA-1794: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) [patch] avoid map look ups in a loop by using entrySet -- Key: CASSANDRA-1794 URL: https://issues.apache.org/jira/browse/CASSANDRA-1794 Project: Cassandra Issue Type: Improvement Components: Core Environment: ubuntu 10.10 jdk1.6.17 ant1.8 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 0.7.0 rc 2 Attachments: avoid_map_lookups.diff Original Estimate: 1h Remaining Estimate: 1h code uses a keyset iterator to loop over a map, doing map look ups each iteration. Switch to entrySet() iterator, to avoid that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1835) null error creating CF from cli
[
https://issues.apache.org/jira/browse/CASSANDRA-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970410#action_12970410
]
Hudson commented on CASSANDRA-1835:
---
Integrated in Cassandra-0.7 #70 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/70/])
null error creating CF from cli
-
Key: CASSANDRA-1835
URL: https://issues.apache.org/jira/browse/CASSANDRA-1835
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0 rc 1
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.7.0
Attachments: CASSANDRA-1835.patch
This fails with only null as the failure message:
{code}
create column family test1 with column_type = 'Super' and comparator =
'LongType' and column_metadata=[{column_name:a,validation_class:LongType}];
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1810) cli support index_type enum names in column_metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970411#action_12970411 ] Hudson commented on CASSANDRA-1810: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) cli support index_type enum names in column_metadata Key: CASSANDRA-1810 URL: https://issues.apache.org/jira/browse/CASSANDRA-1810 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7 beta 3 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.0 rc 2 Attachments: CASSANDRA-1810.patch currently you have to write index_type: 0 when index_type: KEYS would be better -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1832) mx4j does not load
[
https://issues.apache.org/jira/browse/CASSANDRA-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970414#action_12970414
]
Hudson commented on CASSANDRA-1832:
---
Integrated in Cassandra-0.7 #70 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/70/])
mx4j does not load
--
Key: CASSANDRA-1832
URL: https://issues.apache.org/jira/browse/CASSANDRA-1832
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0 rc 1
Environment: CentOS 5.5
Reporter: Rustam Aliyev
Assignee: Ran Tavory
Priority: Minor
Fix For: 0.7.0
Attachments: CASSANDRA-1832.patch
Adding mx4j-tools.jar (latest) to the library causes following exception:
{code}
WARN 20:22:25,123 Could not start register mbean in JMX
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.cassandra.utils.Mx4jTool.maybeLoad(Mx4jTool.java:67)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:169)
at
org.apache.cassandra.thrift.CassandraDaemon.setup(CassandraDaemon.java:55)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:216)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:134)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at
mx4j.tools.adaptor.PlainAdaptorServerSocketFactory.createServerSocket(PlainAdaptorServerSocketFactory.java:24)
at
mx4j.tools.adaptor.http.HttpAdaptor.createServerSocket(HttpAdaptor.java:672)
at mx4j.tools.adaptor.http.HttpAdaptor.start(HttpAdaptor.java:478)
... 9 more
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1805) refactor and remove contrib/
[ https://issues.apache.org/jira/browse/CASSANDRA-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970408#action_12970408 ] Hudson commented on CASSANDRA-1805: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) refactor and remove contrib/ Key: CASSANDRA-1805 URL: https://issues.apache.org/jira/browse/CASSANDRA-1805 Project: Cassandra Issue Type: Task Reporter: Jonathan Ellis Priority: Minor Fix For: 0.8 Contrib is a mix of examples, tools, and miscellanea that probably doesn't belong in our source tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1774) ColumnFamilyOutputFormat only writes one column (per key)
[ https://issues.apache.org/jira/browse/CASSANDRA-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970406#action_12970406 ] Hudson commented on CASSANDRA-1774: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) ColumnFamilyOutputFormat only writes one column (per key) - Key: CASSANDRA-1774 URL: https://issues.apache.org/jira/browse/CASSANDRA-1774 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.7 beta 1 Reporter: Mck SembWever Assignee: Mck SembWever Fix For: 0.7.0 rc 2 Attachments: CASSANDRA-1774.patch From mailing list http://thread.gmane.org/gmane.comp.db.cassandra.user/10385 ColumnFamilyOutputFormat will only write out one column per key. Alex Burkoff also reported this nearly two months ago, but nobody ever replied... http://article.gmane.org/gmane.comp.db.cassandra.user/9325 has anyone any ideas? should it be possible to write multiple columns out? This is very easy to reproduce. Use the contrib/wordcount example, with OUTPUT_REDUCER=cassandra and in WordCount.java add at line 132 results.add(getMutation(key, sum)); +results.add(getMutation(new Text(doubled), sum*2)); Only the last mutation for any key seems to be written. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1804) Quorum calculation code needs to use polymorphic Strategy method for determining replica counts
[ https://issues.apache.org/jira/browse/CASSANDRA-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970407#action_12970407 ] Hudson commented on CASSANDRA-1804: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) Quorum calculation code needs to use polymorphic Strategy method for determining replica counts --- Key: CASSANDRA-1804 URL: https://issues.apache.org/jira/browse/CASSANDRA-1804 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7 beta 1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.7.0 rc 2 Attachments: 1804.txt Keyspace.replication_factor is only valid for SimpleStrategy and ONTS, we shouldn't use it directly anywhere. Related: CASSANDRA-1263 would remove the temptation to do the Wrong Thing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1833) clustertool get_endpoints needs key as String, not ByteBuffer
[ https://issues.apache.org/jira/browse/CASSANDRA-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970412#action_12970412 ] Hudson commented on CASSANDRA-1833: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) clustertool get_endpoints needs key as String, not ByteBuffer - Key: CASSANDRA-1833 URL: https://issues.apache.org/jira/browse/CASSANDRA-1833 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7 beta 3 Environment: all environments Reporter: Kelvin Kakugawa Assignee: Kelvin Kakugawa Priority: Trivial Fix For: 0.7.0 Attachments: CASSANDRA-1833.120710.patch java RMI does not serialize ByteBuffer; revert clustertool to use String for key -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1813) return invalidrequest when client attempts to create secondary index on supercolumns
[ https://issues.apache.org/jira/browse/CASSANDRA-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970413#action_12970413 ] Hudson commented on CASSANDRA-1813: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) return invalidrequest when client attempts to create secondary index on supercolumns Key: CASSANDRA-1813 URL: https://issues.apache.org/jira/browse/CASSANDRA-1813 Project: Cassandra Issue Type: Bug Affects Versions: 0.7 beta 2 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.0 rc 2 Attachments: 1813.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1807) make it easier to turn on the JVM GC debug logging
[ https://issues.apache.org/jira/browse/CASSANDRA-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970409#action_12970409 ] Hudson commented on CASSANDRA-1807: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) make it easier to turn on the JVM GC debug logging -- Key: CASSANDRA-1807 URL: https://issues.apache.org/jira/browse/CASSANDRA-1807 Project: Cassandra Issue Type: Improvement Affects Versions: 0.7.0 rc 1 Reporter: Matthew F. Dennis Assignee: Matthew F. Dennis Priority: Minor Fix For: 0.7.0 rc 2 Attachments: 1807_trunk.txt It's common to need to turn on the JVM GC logging but rather annoying to type / paste it all. It would be much nicer to just have the most common lines commented out in cassandra-env.sh to they could be commented/uncommented as needed - especially when trying to explain to someone over the phone what to enable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1778) Change classloader strategy to load version from non system classloader
[ https://issues.apache.org/jira/browse/CASSANDRA-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970404#action_12970404 ] Hudson commented on CASSANDRA-1778: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) Change classloader strategy to load version from non system classloader --- Key: CASSANDRA-1778 URL: https://issues.apache.org/jira/browse/CASSANDRA-1778 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7 beta 3 Reporter: Bram de Kruijff Assignee: Bram de Kruijff At present when initializing the StorageService, FBUtilities.getReleaseVersionString() tries to load the version.info resource from the ClassLoader.getSystemClassLoader(). This typically fails in an embedded scenario (such as an OSGi container) resulting in a dummy version at INFO and a stacktrace at WARN logger_.warn(Unable to load version.properties, e); return debug version; My guess is that changing the implementation to using the FBUtilities.class.getClassLoader() for loading resources would solve it and will work in almost any case I can think off. However, as discussed on the Apache Felix mailing list, the only rightway to do it is to allow an optional ClassLoader to be specified (@see http://www.mail-archive.com/us...@felix.apache.org/msg09060.html). This issue was initially reported at the Amdatu jira: http://jira.amdatu.org/jira/browse/AMDATU-127 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1814) validation is inefficient
[ https://issues.apache.org/jira/browse/CASSANDRA-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970415#action_12970415 ] Hudson commented on CASSANDRA-1814: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) validation is inefficient - Key: CASSANDRA-1814 URL: https://issues.apache.org/jira/browse/CASSANDRA-1814 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 rc 1 Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.7.0 Attachments: v3-0001-type-validations-that-generate-less-garbage.txt We do all validation by simply calling AbstractType.getString(). This generates garbage needlessly and has a lot of overhead. A simpler interface would be to make AbstractType.validate abstract and have the child classes implement it in an intelligent and efficient way. EDIT: Somewhat related: It looks like we're attempting to validate column names in ThriftValidation.validateColumns(). Is this intentional? Nevermind that part. I get it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1784) [patch] don't include ant runtimes on javac
[ https://issues.apache.org/jira/browse/CASSANDRA-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970416#action_12970416 ] Hudson commented on CASSANDRA-1784: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) [patch] don't include ant runtimes on javac --- Key: CASSANDRA-1784 URL: https://issues.apache.org/jira/browse/CASSANDRA-1784 Project: Cassandra Issue Type: Improvement Affects Versions: 0.7 beta 3 Environment: ubuntu10.10 java1.6.17 ant 1.8 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Attachments: turn_off_antruntime.diff Original Estimate: 1h Remaining Estimate: 1h by default javac pulls in ant runtime libraries, which are not needed in building cassandra. Just slows the build, and emits warning messages when using ant 1.8 and better. patch removes them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1789) Clean up (and make sane) key/row cache loading logspam
[ https://issues.apache.org/jira/browse/CASSANDRA-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970423#action_12970423 ] Hudson commented on CASSANDRA-1789: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) Clean up (and make sane) key/row cache loading logspam -- Key: CASSANDRA-1789 URL: https://issues.apache.org/jira/browse/CASSANDRA-1789 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.6.8, 0.7 beta 3 Environment: Default settings, init log. Reporter: Jon Hermes Assignee: Matthew F. Dennis Priority: Minor Fix For: 0.6.9, 0.7.0 rc 2 Attachments: 1789-trunk.txt //Start INFO 19:18:03,362 Heap size: 1935147008/1994063872 INFO 19:18:03,366 JNA not found. Native methods will be disabled. INFO 19:18:03,376 Loading settings from file:/home/hermes/work/c/cass7/conf/cassandra.yaml INFO 19:18:03,533 DiskAccessMode 'auto' determined to be mmap, indexAccessMode is mmap INFO 19:18:03,612 Creating new commitlog segment /var/lib/cassandra/commitlog/CommitLog-1291079883612.log //Keycache loading *INFO 19:18:03,659 read 0 from saved key cache* *INFO 19:18:03,663 read 0 from saved key cache* *INFO 19:18:03,664 read 0 from saved key cache* *INFO 19:18:03,666 read 0 from saved key cache* *INFO 19:18:03,668 read 0 from saved key cache* //Rowcache loading *INFO 19:18:03,671 loading row cache for LocationInfo of system* *INFO 19:18:03,671 completed loading (0 ms; 0 keys) row cache for LocationInfo of system* *INFO 19:18:03,672 loading row cache for HintsColumnFamily of system* *INFO 19:18:03,672 completed loading (0 ms; 0 keys) row cache for HintsColumnFamily of system* *INFO 19:18:03,673 loading row cache for Migrations of system* *INFO 19:18:03,673 completed loading (0 ms; 0 keys) row cache for Migrations of system* *INFO 19:18:03,676 loading row cache for Schema of system* *INFO 19:18:03,676 completed loading (0 ms; 0 keys) row cache for Schema of system* *INFO 19:18:03,676 loading row cache for IndexInfo of system* *INFO 19:18:03,677 completed loading (0 ms; 0 keys) row cache for IndexInfo of system* //The rest INFO 19:18:03,730 Couldn't detect any schema definitions in local storage. INFO 19:18:03,731 Found table data in data directories. Consider using JMX to call org.apache.cassandra.service.StorageService.loadSchemaFromYaml(). INFO 19:18:03,735 No commitlog files found; skipping replay INFO 19:18:03,783 Upgrading to 0.7. Purging hints if there are any. Old hints will be snapshotted. INFO 19:18:03,786 Cassandra version: 0.7.0-rc1-SNAPSHOT INFO 19:18:03,786 Thrift API version: 19.4.0 INFO 19:18:03,795 Loading persisted ring state INFO 19:18:03,796 Starting up server gossip INFO 19:18:03,803 switching in a fresh Memtable for LocationInfo at CommitLogContext(file='/var/lib/cassandra/commitlog/CommitLog-1291079883612.log', position=700) INFO 19:18:03,804 Enqueuing flush of memtable-locationi...@1249086728(227 bytes, 4 operations) INFO 19:18:03,805 Writing memtable-locationi...@1249086728(227 bytes, 4 operations) INFO 19:18:03,992 Completed flushing /var/lib/cassandra/data/system/LocationInfo-e-1-Data.db (473 bytes) WARN 19:18:04,058 Generated random token 10930265816036509614621074423558283. Random tokens will result in an unbalanced ring; see http://wiki.apache.org/cassandra/Operations INFO 19:18:04,059 switching in a fresh Memtable for LocationInfo at CommitLogContext(file='/var/lib/cassandra/commitlog/CommitLog-1291079883612.log', position=996) INFO 19:18:04,060 Enqueuing flush of memtable-locationi...@1940835386(53 bytes, 2 operations) INFO 19:18:04,060 Writing memtable-locationi...@1940835386(53 bytes, 2 operations) INFO 19:18:04,258 Completed flushing /var/lib/cassandra/data/system/LocationInfo-e-2-Data.db (301 bytes) INFO 19:18:04,269 Will not load MX4J, mx4j-tools.jar is not in the classpath INFO 19:18:04,301 Binding thrift service to localhost/127.0.0.1:9160 INFO 19:18:04,304 Using TFramedTransport with a max frame size of 15728640 bytes. INFO 19:18:04,307 Listening for thrift clients... The logging here is annoying (and a bit schizophrenic). Either the keycache loading logging should include as much info as the rowcache loading (time duration, CF/KS names) or it should be a much smaller snippet for both. The best fix would probably be the line: *INFO XX:XX:XX,XXX completed loading (time; keys) row/key cache for CF in KS.* ...which would be a log line per CF per saved key/row cache (with more logging on error). I don't know if logging that 0 rows (key or row cache) successfully loaded is
[jira] Commented: (CASSANDRA-1764) NPE on system_update_cf when adding an index to a column without existing metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970417#action_12970417 ] Hudson commented on CASSANDRA-1764: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) NPE on system_update_cf when adding an index to a column without existing metadata -- Key: CASSANDRA-1764 URL: https://issues.apache.org/jira/browse/CASSANDRA-1764 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 rc 1 Environment: Cassandra 0.7 branch Reporter: Tyler Hobbs Assignee: Gary Dusbabek Fix For: 0.7.0 rc 2 Attachments: 1764-test-v2.txt, 1764-test.txt When trying to create a secondary index using system_update_column_family(), if you try to add an index on a column that does not already have an existing entry in the CfDef's column_metadata, a NullPointerException is thrown. Looks like the logic in o.a.c.config.CFMetaData.apply() is faulty. Specifically, creating a toUpdate Set (similar to the toAdd and toDelete) sets and using that for the loop ~ line 663 would fix this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1780) periodic + flush commitlog mode
[ https://issues.apache.org/jira/browse/CASSANDRA-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970419#action_12970419 ] Hudson commented on CASSANDRA-1780: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) periodic + flush commitlog mode --- Key: CASSANDRA-1780 URL: https://issues.apache.org/jira/browse/CASSANDRA-1780 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.0 rc 2 Attachments: 1780.txt periodic-sync commitlog mode only flushes before it syncs, which means its best case durability is very similar to its worst case. if we had a mode that flushed but did not sync then it would only lose data for actual power failures. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1763) NodeCmd should be able to view Compaction Statistics
[
https://issues.apache.org/jira/browse/CASSANDRA-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970418#action_12970418
]
Hudson commented on CASSANDRA-1763:
---
Integrated in Cassandra-0.7 #70 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/70/])
NodeCmd should be able to view Compaction Statistics
Key: CASSANDRA-1763
URL: https://issues.apache.org/jira/browse/CASSANDRA-1763
Project: Cassandra
Issue Type: New Feature
Components: Core
Affects Versions: 0.7 beta 3
Reporter: Edward Capriolo
Assignee: Edward Capriolo
Priority: Minor
Fix For: 0.7.0
Attachments: cassandra-1763-2-branch-7.0.patch.txt,
cassandra-1763-patch.txt
When joining a node, major compacting a node, running cleanup on a node, or
sometimes when a node seems slightly slow it would be helpful to get
compaction information with nodetool
nodetool compactionstats would produce:
{noformat}
compaction type: Major
column family: standard1
bytes compacted: 49925478
bytes total in progress: 63555680
pending tasks: 1
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1768) UnsupportedOperationException in system_update_column_family
[
https://issues.apache.org/jira/browse/CASSANDRA-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970421#action_12970421
]
Hudson commented on CASSANDRA-1768:
---
Integrated in Cassandra-0.7 #70 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/70/])
UnsupportedOperationException in system_update_column_family
Key: CASSANDRA-1768
URL: https://issues.apache.org/jira/browse/CASSANDRA-1768
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0 rc 1
Reporter: T Jake Luciani
Assignee: Gary Dusbabek
Fix For: 0.7.0 rc 2
Attachments: v0-0001-fix-add-remove-index-bugs-in-CFMetadata.txt
During testing I hit this section of code:
CFMetaData.java:662
{code}
// remove the ones leaving.
for (ByteBuffer indexName : toRemove)
column_metadata.remove(indexName);
{code}
but column_metadata is defined as:
{code}
this.column_metadata = Collections.unmodifiableMap(column_metadata);
{code}
So remove() will throw an exception.
{code}
java.lang.UnsupportedOperationException
at java.util.Collections$UnmodifiableMap.remove(Collections.java:1288)
at org.apache.cassandra.config.CFMetaData.apply(CFMetaData.java:662)
at
org.apache.cassandra.db.migration.UpdateColumnFamily.init(UpdateColumnFamily.java:56)
at
org.apache.cassandra.thrift.CassandraServer.system_update_column_family(CassandraServer.java:863)
at
org.apache.cassandra.thrift.Cassandra$Processor$system_update_column_family.process(Cassandra.java:3592)
at
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2555)
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:680)
{code}
This was introduced by CASSANDRA-1715
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1838) Add ability to set TTL on columns in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970420#action_12970420 ] Hudson commented on CASSANDRA-1838: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) Add ability to set TTL on columns in cassandra-cli -- Key: CASSANDRA-1838 URL: https://issues.apache.org/jira/browse/CASSANDRA-1838 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.7.0 rc 1 Environment: Ubuntu 10.04 64bit Reporter: Eric Tamme Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.0 Attachments: CASSANDRA-1838-v2.patch, CASSANDRA-1838.patch Currently the cassandra-cli does not have any mechanism to set the ttl attribute of a column. This would be a useful ability to have when working with the cli tool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1767) cli to/from string needs to move into AbstractType
[ https://issues.apache.org/jira/browse/CASSANDRA-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970422#action_12970422 ] Hudson commented on CASSANDRA-1767: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) cli to/from string needs to move into AbstractType -- Key: CASSANDRA-1767 URL: https://issues.apache.org/jira/browse/CASSANDRA-1767 Project: Cassandra Issue Type: Improvement Components: Core, Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.0 rc 2 Attachments: CASSANDRA-1767.patch currently CLI cannot use custom data types since it doesn't know how to turn user-input strings into binary data. need to add ByteBuffer fromString(String) to AbstractType and move the conversion code from CliClient there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1786) [patch] use cross platform new lines in printf calls
[ https://issues.apache.org/jira/browse/CASSANDRA-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970426#action_12970426 ] Hudson commented on CASSANDRA-1786: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) [patch] use cross platform new lines in printf calls Key: CASSANDRA-1786 URL: https://issues.apache.org/jira/browse/CASSANDRA-1786 Project: Cassandra Issue Type: Bug Affects Versions: 0.7 beta 3 Environment: ubuntu10.10 java 1.6.17 ant 1.8 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 0.7.0 rc 2 Attachments: use_crossplatform_newlines.diff Original Estimate: 1h Remaining Estimate: 1h code uses printf(\n) for new lines, should use %n instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1316) Read repair does not always work correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970427#action_12970427 ] Hudson commented on CASSANDRA-1316: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) Read repair does not always work correctly -- Key: CASSANDRA-1316 URL: https://issues.apache.org/jira/browse/CASSANDRA-1316 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.4 Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 0.6.4 Attachments: 001_correct_responsecount_in_RRR.txt, 1316-RRM.txt, cassandra-1.json, cassandra-2.json, cassandra-3.json, RRR-v2.txt Read repair does not always work. At the least, we allow violation of the CL.ALL contract. To reproduce, create a three node cluster with RF=3, and json2sstable one of the attached json files on each node. This creates a row whose key is 'test' with 9 columns, but only 3 columns are on each machine. If you get_count this row in quick succession at CL.ALL, sometimes you will receive a count of 6, sometimes 9. After the ReadRepairManager has sent the repairs, you will always get 9, which is the desired behavior. I have another data set obtained in the wild which never fully repairs for some reason, but it's a bit large to attach (600ish columns per machine.) I'm still trying to figure out why RR isn't working on this set, but I always get different results when reading at any CL including ALL, no matter how long I wait or how many reads I do. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1785) [patch] use long math, if long values are expected.
[ https://issues.apache.org/jira/browse/CASSANDRA-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970425#action_12970425 ] Hudson commented on CASSANDRA-1785: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) [patch] use long math, if long values are expected. --- Key: CASSANDRA-1785 URL: https://issues.apache.org/jira/browse/CASSANDRA-1785 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7 beta 3 Environment: ubuntu10.10 java1.6.17 ant1.8 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 0.7.0 rc 2 Attachments: use_long_math.diff Original Estimate: 1h Remaining Estimate: 1h code does math assuming the result is a long, but uses integer math. Might as well use long math to avoid possible truncation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1762) UpdateKeyspace does not modify strategy or strategy_options (until restart)
[ https://issues.apache.org/jira/browse/CASSANDRA-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970424#action_12970424 ] Hudson commented on CASSANDRA-1762: --- Integrated in Cassandra-0.7 #70 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/70/]) UpdateKeyspace does not modify strategy or strategy_options (until restart) --- Key: CASSANDRA-1762 URL: https://issues.apache.org/jira/browse/CASSANDRA-1762 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7 beta 2 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.7.0 rc 2 Attachments: 1762.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
