[jira] [Commented] (CASSANDRA-9312) Provide a way to retrieve the write time of a CQL row
[ https://issues.apache.org/jira/browse/CASSANDRA-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635204#comment-16635204 ] Radim Kolar commented on CASSANDRA-9312: I have this problem too - rows only with primary key columns, i need function writetime to work on primary columns. For me it is enough to implement it that way so it fails if there are any non primary key columns and you are trying to get timestamp for primary column. > Provide a way to retrieve the write time of a CQL row > - > > Key: CASSANDRA-9312 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9312 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Nicolas Favre-Felix >Priority: Major > Fix For: 2.2.x > > > There is currently no way to retrieve the "writetime" of a CQL row. This is > an issue for tables in which all dimensions are part of the primary key. > Since Cassandra already stores a cell for the CQL row, it would make sense to > provide a way to read its timestamp. This feature would be consistent with > the concept of a row as an entity containing a number of optional columns, > but able to exist on its own. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7365) some compactions do not works under windows (file in use during rename)
[ https://issues.apache.org/jira/browse/CASSANDRA-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-7365: --- Attachment: cassandra.yaml some compactions do not works under windows (file in use during rename) --- Key: CASSANDRA-7365 URL: https://issues.apache.org/jira/browse/CASSANDRA-7365 Project: Cassandra Issue Type: Bug Components: Core Environment: jdk7, cassandra-2.1rc1, os windows 32 bit Reporter: Radim Kolar Assignee: Joshua McKenzie Labels: Windows Fix For: 2.1.0 Attachments: cassandra.yaml, system.log compaction do not works under windows due to file rename fails: (Pro es nemß p°Ýstup k souboru, neboŁ jej prßvý vyu×Ývß jinř proces = process can not access file because its in use by another process). Not all compactions are broken. compactions done during server startup on system tables works fine. INFO 18:30:27 Completed flushing c:\cassandra-2.1\data\system\compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b\system-compactions_in_progress-ka-6-Dat.db (42 bytes) for commitlog position ReplayPosition(segmentId=1402165543361, psition=8024611) ERROR 18:30:27 Exception in thread hread[CompactionExecutor:5,1,RMI Runtime] java.lang.RuntimeException: Failed to rename c:\cassandra-2.1\data\test\sipdb-5 f51090ee6511e3815625991ef2b954\test-sipdb-tmp-ka-7-Index.db to c:\cassandra-2.1 data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-7-Index.db at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.j va:167) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.j va:151) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.j va:512) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.j va:504) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.close(SSTableWriter.ja a:479) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SST bleWriter.java:427) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SST bleWriter.java:422) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableRewriter.finish(SSTableRewrit r.java:312) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableRewriter.finish(SSTableRewrit r.java:306) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionTask.runWith(Compaction ask.java:188) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAware unnable.java:48) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java: 8) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionTask.executeInternal(Co pactionTask.java:74) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(Ab tractCompactionTask.java:59) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompa tionTask.run(CompactionManager.java:235) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0 rc1] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:4 1) ~[na:1.7.0_60] at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_ 0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor java:1145) ~[na:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto .java:615) [na:1.7.0_60] at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60] Caused by: java.nio.file.FileSystemException: c:\cassandra-2.1\data\test\sipdb- 8f51090ee6511e3815625991ef2b954\test-sipdb-tmp-ka-7-Index.db - c:\cassandra-2. \data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-7-Index.db: Pro es nemß p°Ýstup k souboru, neboŁ jej prßvý vyu×Ývß jinř proces. at sun.nio.fs.WindowsException.translateToIOException(WindowsException. ava:86) ~[na:1.7.0_60] at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.ja a:97) ~[na:1.7.0_60] at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:301) ~[na:1.7.0 60] at
[jira] [Updated] (CASSANDRA-7365) some compactions do not works under windows (file in use during rename)
[ https://issues.apache.org/jira/browse/CASSANDRA-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-7365: --- Attachment: system.log some compactions do not works under windows (file in use during rename) --- Key: CASSANDRA-7365 URL: https://issues.apache.org/jira/browse/CASSANDRA-7365 Project: Cassandra Issue Type: Bug Components: Core Environment: jdk7, cassandra-2.1rc1, os windows 32 bit Reporter: Radim Kolar Assignee: Joshua McKenzie Labels: Windows Fix For: 2.1.0 Attachments: cassandra.yaml, system.log compaction do not works under windows due to file rename fails: (Pro es nemß p°Ýstup k souboru, neboŁ jej prßvý vyu×Ývß jinř proces = process can not access file because its in use by another process). Not all compactions are broken. compactions done during server startup on system tables works fine. INFO 18:30:27 Completed flushing c:\cassandra-2.1\data\system\compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b\system-compactions_in_progress-ka-6-Dat.db (42 bytes) for commitlog position ReplayPosition(segmentId=1402165543361, psition=8024611) ERROR 18:30:27 Exception in thread hread[CompactionExecutor:5,1,RMI Runtime] java.lang.RuntimeException: Failed to rename c:\cassandra-2.1\data\test\sipdb-5 f51090ee6511e3815625991ef2b954\test-sipdb-tmp-ka-7-Index.db to c:\cassandra-2.1 data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-7-Index.db at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.j va:167) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.j va:151) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.j va:512) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.j va:504) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.close(SSTableWriter.ja a:479) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SST bleWriter.java:427) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SST bleWriter.java:422) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableRewriter.finish(SSTableRewrit r.java:312) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableRewriter.finish(SSTableRewrit r.java:306) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionTask.runWith(Compaction ask.java:188) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAware unnable.java:48) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java: 8) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionTask.executeInternal(Co pactionTask.java:74) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(Ab tractCompactionTask.java:59) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompa tionTask.run(CompactionManager.java:235) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0 rc1] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:4 1) ~[na:1.7.0_60] at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_ 0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor java:1145) ~[na:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto .java:615) [na:1.7.0_60] at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60] Caused by: java.nio.file.FileSystemException: c:\cassandra-2.1\data\test\sipdb- 8f51090ee6511e3815625991ef2b954\test-sipdb-tmp-ka-7-Index.db - c:\cassandra-2. \data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-7-Index.db: Pro es nemß p°Ýstup k souboru, neboŁ jej prßvý vyu×Ývß jinř proces. at sun.nio.fs.WindowsException.translateToIOException(WindowsException. ava:86) ~[na:1.7.0_60] at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.ja a:97) ~[na:1.7.0_60] at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:301) ~[na:1.7.0 60] at
[jira] [Commented] (CASSANDRA-7365) some compactions do not works under windows (file in use during rename)
[ https://issues.apache.org/jira/browse/CASSANDRA-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025621#comment-14025621 ] Radim Kolar commented on CASSANDRA-7365: every time against that keyspace some compactions do not works under windows (file in use during rename) --- Key: CASSANDRA-7365 URL: https://issues.apache.org/jira/browse/CASSANDRA-7365 Project: Cassandra Issue Type: Bug Components: Core Environment: jdk7, cassandra-2.1rc1, os windows 32 bit Reporter: Radim Kolar Assignee: Joshua McKenzie Labels: Windows Fix For: 2.1.0 Attachments: cassandra.yaml, system.log compaction do not works under windows due to file rename fails: (Pro es nemß p°Ýstup k souboru, neboŁ jej prßvý vyu×Ývß jinř proces = process can not access file because its in use by another process). Not all compactions are broken. compactions done during server startup on system tables works fine. INFO 18:30:27 Completed flushing c:\cassandra-2.1\data\system\compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b\system-compactions_in_progress-ka-6-Dat.db (42 bytes) for commitlog position ReplayPosition(segmentId=1402165543361, psition=8024611) ERROR 18:30:27 Exception in thread hread[CompactionExecutor:5,1,RMI Runtime] java.lang.RuntimeException: Failed to rename c:\cassandra-2.1\data\test\sipdb-5 f51090ee6511e3815625991ef2b954\test-sipdb-tmp-ka-7-Index.db to c:\cassandra-2.1 data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-7-Index.db at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.j va:167) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.j va:151) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.j va:512) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.j va:504) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.close(SSTableWriter.ja a:479) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SST bleWriter.java:427) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SST bleWriter.java:422) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableRewriter.finish(SSTableRewrit r.java:312) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableRewriter.finish(SSTableRewrit r.java:306) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionTask.runWith(Compaction ask.java:188) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAware unnable.java:48) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java: 8) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionTask.executeInternal(Co pactionTask.java:74) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(Ab tractCompactionTask.java:59) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompa tionTask.run(CompactionManager.java:235) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0 rc1] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:4 1) ~[na:1.7.0_60] at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_ 0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor java:1145) ~[na:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto .java:615) [na:1.7.0_60] at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60] Caused by: java.nio.file.FileSystemException: c:\cassandra-2.1\data\test\sipdb- 8f51090ee6511e3815625991ef2b954\test-sipdb-tmp-ka-7-Index.db - c:\cassandra-2. \data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-7-Index.db: Pro es nemß p°Ýstup k souboru, neboŁ jej prßvý vyu×Ývß jinř proces. at sun.nio.fs.WindowsException.translateToIOException(WindowsException. ava:86) ~[na:1.7.0_60] at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.ja a:97) ~[na:1.7.0_60] at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:301)
[jira] [Created] (CASSANDRA-7364) assert error in StorageProxy.submitHint
Radim Kolar created CASSANDRA-7364: -- Summary: assert error in StorageProxy.submitHint Key: CASSANDRA-7364 URL: https://issues.apache.org/jira/browse/CASSANDRA-7364 Project: Cassandra Issue Type: Bug Components: Core Environment: cassandra 2.1-rc1, os windows, 32 bit Reporter: Radim Kolar Priority: Blocker Fix For: 2.1 rc1 in 2.1-rc1. assert error and hector based client ends with all nodes down message (its single node cluster). I assume that client connection got closed. INFO 18:28:33 Compacting [SSTableReader(path='c:\cassandra-2.1\data\test\sipdb- 58f51090ee6511e3815625991ef2b954\test-sipdb-ka-3-Data.db'), SSTableReader(path=' c:\cassandra-2.1\data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka- 1-Data.db'), SSTableReader(path='c:\cassandra-2.1\data\test\sipdb-58f51090ee6511 e3815625991ef2b954\test-sipdb-ka-4-Data.db'), SSTableReader(path='c:\cassandra-2 .1\data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-2-Data.db'), S STableReader(path='c:\cassandra-2.1\data\test\sipdb-58f51090ee6511e3815625991ef2 b954\test-sipdb-ka-6-Data.db')] ERROR 18:29:50 Exception in thread Thread[Thrift:16,5,main] java.lang.AssertionError: localhost/127.0.0.1 at org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.jav a:870) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:49 3) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageP roxy.java:537) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer. java:1095) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer. java:1077) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraSer ver.java:970) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResul t(Cassandra.java:3996) ~[apache-cassandra-thrift-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResul t(Cassandra.java:3980) ~[apache-cassandra-thrift-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39) ~[ libthrift-0.9.1.jar:0.9.1] at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) ~[li bthrift-0.9.1.jar:0.9.1] at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run (CustomTThreadPoolServer.java:201) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) ~[na:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:615) ~[na:1.7.0_60] at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60] INFO 18:29:55 1 MUTATION messages dropped in last 5000ms -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7365) some compactions do not works under windows (file in use during rename)
Radim Kolar created CASSANDRA-7365: -- Summary: some compactions do not works under windows (file in use during rename) Key: CASSANDRA-7365 URL: https://issues.apache.org/jira/browse/CASSANDRA-7365 Project: Cassandra Issue Type: Bug Components: Core Environment: jdk7, cassandra-2.1rc1, os windows 32 bit Reporter: Radim Kolar Fix For: 2.1.0 compaction do not works under windows due to file rename fails: (Pro es nemß p°Ýstup k souboru, neboŁ jej prßvý vyu×Ývß jinř proces = process can not access file because its in use by another process). Not all compactions are broken. compactions done during server startup on system tables works fine. INFO 18:30:27 Completed flushing c:\cassandra-2.1\data\system\compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b\system-compactions_in_progress-ka-6-Dat.db (42 bytes) for commitlog position ReplayPosition(segmentId=1402165543361, psition=8024611) ERROR 18:30:27 Exception in thread hread[CompactionExecutor:5,1,RMI Runtime] java.lang.RuntimeException: Failed to rename c:\cassandra-2.1\data\test\sipdb-5 f51090ee6511e3815625991ef2b954\test-sipdb-tmp-ka-7-Index.db to c:\cassandra-2.1 data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-7-Index.db at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.j va:167) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.j va:151) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.j va:512) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.j va:504) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.close(SSTableWriter.ja a:479) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SST bleWriter.java:427) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SST bleWriter.java:422) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableRewriter.finish(SSTableRewrit r.java:312) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.sstable.SSTableRewriter.finish(SSTableRewrit r.java:306) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionTask.runWith(Compaction ask.java:188) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAware unnable.java:48) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java: 8) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionTask.executeInternal(Co pactionTask.java:74) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(Ab tractCompactionTask.java:59) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompa tionTask.run(CompactionManager.java:235) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0 rc1] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:4 1) ~[na:1.7.0_60] at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_ 0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor java:1145) ~[na:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto .java:615) [na:1.7.0_60] at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60] Caused by: java.nio.file.FileSystemException: c:\cassandra-2.1\data\test\sipdb- 8f51090ee6511e3815625991ef2b954\test-sipdb-tmp-ka-7-Index.db - c:\cassandra-2. \data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-7-Index.db: Pro es nemß p°Ýstup k souboru, neboŁ jej prßvý vyu×Ývß jinř proces. at sun.nio.fs.WindowsException.translateToIOException(WindowsException. ava:86) ~[na:1.7.0_60] at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.ja a:97) ~[na:1.7.0_60] at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:301) ~[na:1.7.0 60] at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider. ava:287) ~[na:1.7.0_60] at java.nio.file.Files.move(Files.java:1347) ~[na:1.7.0_60] at org.apache.cassandra.io.util.FileUtils.atomicMoveWithFallback(FileUt ls.java:181) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.j va:163) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1] ... 19 common frames omitted INFO 18:30:27
[jira] [Commented] (CASSANDRA-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13861481#comment-13861481
]
Radim Kolar commented on CASSANDRA-4687:
Any experience from testing new version in customer test environment?
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Priority: Minor
Attachments: 4687-debugging.txt,
apache-cassandra-1.2.13-SNAPSHOT.jar, guava-backed-cache.patch
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841437#comment-13841437
]
Radim Kolar commented on CASSANDRA-4687:
I agree with you, its serious problem. It is in C 1.1 up to 2.0. I do not
recommend anybody to run these versions for mission critical workloads.
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Priority: Minor
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CASSANDRA-6032) shuffle fails with NumberFormatException
Radim Kolar created CASSANDRA-6032: -- Summary: shuffle fails with NumberFormatException Key: CASSANDRA-6032 URL: https://issues.apache.org/jira/browse/CASSANDRA-6032 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Radim Kolar INFO 12:42:56,906 Removing RELOCATION state for /10.0.0.3 -6470120033327209844 INFO 12:46:41,656 Enabling scheduled transfers of token ranges INFO 12:46:41,656 Initiating transfer of -6730365637522478358 (scheduled at Sun Sep 15 12:41:14 CEST 2013) WARN 12:46:41,656 cannot move -6730365637522478358; source and destination match WARN 12:46:41,656 no valid token arguments specified; nothing to relocate ERROR 12:46:41,656 Error removing -6730365637522478358: java.lang.NumberFormatException: For input string: ERROR 12:46:41,875 Exception in thread Thread[GossipStage:1,5,main] java.lang.NumberFormatException: For input string: at java.lang.NumberFormatException.forInputString(NumberFormatException. java:65) at java.lang.Long.parseLong(Long.java:453) at java.lang.Long.valueOf(Long.java:540) at org.apache.cassandra.dht.Murmur3Partitioner$1.fromString(Murmur3Parti tioner.java:183) at org.apache.cassandra.service.StorageService.handleStateRelocating(Sto rageService.java:1490) at org.apache.cassandra.service.StorageService.onChange(StorageService.j ava:1180) at org.apache.cassandra.gms.Gossiper.doNotifications(Gossiper.java:956) at org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:947) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:905 ) at org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDige stAckVerbHandler.java:57) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask. java:56) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:615) at java.lang.Thread.run(Thread.java:724) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-6032) shuffle fails with NumberFormatException
[ https://issues.apache.org/jira/browse/CASSANDRA-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13767771#comment-13767771 ] Radim Kolar commented on CASSANDRA-6032: on other token it fails too, but stacktrace is not there INFO 13:03:14,078 Shutting down range transfer scheduler INFO 13:03:19,421 Enabling scheduled transfers of token ranges INFO 13:03:19,421 Initiating transfer of -6470120033327209844 (scheduled at Sun Sep 15 12:52:27 CEST 2013) WARN 13:03:19,421 cannot move -6470120033327209844; source and destination matc WARN 13:03:19,421 no valid token arguments specified; nothing to relocate RROR 13:03:19,421 Error removing -6470120033327209844: java.lang.NumberFormatEx eption: For input string: shuffle fails with NumberFormatException Key: CASSANDRA-6032 URL: https://issues.apache.org/jira/browse/CASSANDRA-6032 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Radim Kolar INFO 12:42:56,906 Removing RELOCATION state for /10.0.0.3 -6470120033327209844 INFO 12:46:41,656 Enabling scheduled transfers of token ranges INFO 12:46:41,656 Initiating transfer of -6730365637522478358 (scheduled at Sun Sep 15 12:41:14 CEST 2013) WARN 12:46:41,656 cannot move -6730365637522478358; source and destination match WARN 12:46:41,656 no valid token arguments specified; nothing to relocate ERROR 12:46:41,656 Error removing -6730365637522478358: java.lang.NumberFormatException: For input string: ERROR 12:46:41,875 Exception in thread Thread[GossipStage:1,5,main] java.lang.NumberFormatException: For input string: at java.lang.NumberFormatException.forInputString(NumberFormatException. java:65) at java.lang.Long.parseLong(Long.java:453) at java.lang.Long.valueOf(Long.java:540) at org.apache.cassandra.dht.Murmur3Partitioner$1.fromString(Murmur3Parti tioner.java:183) at org.apache.cassandra.service.StorageService.handleStateRelocating(Sto rageService.java:1490) at org.apache.cassandra.service.StorageService.onChange(StorageService.j ava:1180) at org.apache.cassandra.gms.Gossiper.doNotifications(Gossiper.java:956) at org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:947) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:905 ) at org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDige stAckVerbHandler.java:57) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask. java:56) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:615) at java.lang.Thread.run(Thread.java:724) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5873) shuffle clear fails
Radim Kolar created CASSANDRA-5873: -- Summary: shuffle clear fails Key: CASSANDRA-5873 URL: https://issues.apache.org/jira/browse/CASSANDRA-5873 Project: Cassandra Issue Type: Bug Reporter: Radim Kolar C:\cassandra2\binshuffle.bat clear Exception in thread main java.lang.RuntimeException: org.apache.thrift.TApplic ationException: Internal error processing execute_cql3_query at org.apache.cassandra.tools.Shuffle.executeCqlQuery(Shuffle.java:516) at org.apache.cassandra.tools.Shuffle.clear(Shuffle.java:439) at org.apache.cassandra.tools.Shuffle.main(Shuffle.java:689) Caused by: org.apache.thrift.TApplicationException: Internal error processing ex ecute_cql3_query at org.apache.thrift.TApplicationException.read(TApplicationException.ja va:108) at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:71) at org.apache.cassandra.thrift.Cassandra$Client.recv_execute_cql3_query( Cassandra.java:1636) at org.apache.cassandra.thrift.Cassandra$Client.execute_cql3_query(Cassa ndra.java:1621) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5874) exception on startup
Radim Kolar created CASSANDRA-5874: -- Summary: exception on startup Key: CASSANDRA-5874 URL: https://issues.apache.org/jira/browse/CASSANDRA-5874 Project: Cassandra Issue Type: Bug Reporter: Radim Kolar INFO 10:10:34,375 Handshaking version with /10.0.0.3 WARN 10:10:43,734 Skipped default superuser setup: some nodes were not ready INFO 10:10:44,656 Node /10.0.0.3 has restarted, now UP INFO 10:10:44,687 Handshaking version with /10.0.0.3 ERROR 10:10:44,687 Exception in thread Thread[GossipStage:1,5,main] java.lang.NumberFormatException: For input string: at java.lang.NumberFormatException.forInputString(NumberFormatException. java:65) at java.lang.Long.parseLong(Long.java:453) at java.lang.Long.valueOf(Long.java:540) at org.apache.cassandra.dht.Murmur3Partitioner$1.fromString(Murmur3Parti tioner.java:183) at org.apache.cassandra.service.StorageService.handleStateRelocating(Sto rageService.java:1490) at org.apache.cassandra.service.StorageService.onChange(StorageService.j ava:1180) at org.apache.cassandra.service.StorageService.onJoin(StorageService.jav a:1888) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.jav a:844) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:895 ) at org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDige stAckVerbHandler.java:57) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask. java:56) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:615) at java.lang.Thread.run(Thread.java:724) INFO 10:10:44,796 InetAddress /10.0.0.3 is now UP -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5876) shuffle create fails
Radim Kolar created CASSANDRA-5876: -- Summary: shuffle create fails Key: CASSANDRA-5876 URL: https://issues.apache.org/jira/browse/CASSANDRA-5876 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Radim Kolar it does something, then fails ~~+~~~+~~~ 20:23 450278428465709172510.0.0.110.0.0.3 -2605626125862936133 10.0.0.110.0.0.3 889219864993465969210.0.0.110.0.0.3 -6470120033327209844 10.0.0.110.0.0.3 -8907653413352045189 10.0.0.110.0.0.3 -9062237682932646949 10.0.0.110.0.0.3 60589390902386510.0.0.110.0.0.3 683355368177055097610.0.0.110.0.0.3 Exception in thread main java.lang.RuntimeException: org.apache.thrift.TApplic ationException: Internal error processing execute_cql3_query at org.apache.cassandra.tools.Shuffle.executeCqlQuery(Shuffle.java:516) at org.apache.cassandra.tools.Shuffle.shuffle(Shuffle.java:359) at org.apache.cassandra.tools.Shuffle.main(Shuffle.java:681) Caused by: org.apache.thrift.TApplicationException: Internal error processing ex ecute_cql3_query at org.apache.thrift.TApplicationException.read(TApplicationException.ja va:108) at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:71) at org.apache.cassandra.thrift.Cassandra$Client.recv_execute_cql3_query( Cassandra.java:1636) at org.apache.cassandra.thrift.Cassandra$Client.execute_cql3_query(Cassa ndra.java:1621) at org.apache.cassandra.tools.CassandraClient.execute_cql_query(Shuffle. java:736) at org.apache.cassandra.tools.Shuffle.executeCqlQuery(Shuffle.java:502) ... 2 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5862) Switch to adler checksum for sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733752#comment-13733752 ] Radim Kolar commented on CASSANDRA-5862: Adler is unreliable, i had bad experience with it, switched from crc32 to adler for a while. Use CRC32C. Switch to adler checksum for sstables - Key: CASSANDRA-5862 URL: https://issues.apache.org/jira/browse/CASSANDRA-5862 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: T Jake Luciani Fix For: 2.0.1 Adler is significantly faster than CRC32: http://java-performance.info/java-crc32-and-adler32/ (Adler is weaker for short inputs, so we should leave the commitlog alone, as it checksums each mutation individually.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5862) Switch to adler checksum for sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733792#comment-13733792 ] Radim Kolar commented on CASSANDRA-5862: 60-80 bytes Switch to adler checksum for sstables - Key: CASSANDRA-5862 URL: https://issues.apache.org/jira/browse/CASSANDRA-5862 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: T Jake Luciani Fix For: 2.0.1 Adler is significantly faster than CRC32: http://java-performance.info/java-crc32-and-adler32/ (Adler is weaker for short inputs, so we should leave the commitlog alone, as it checksums each mutation individually.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5862) Switch to adler checksum for sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733923#comment-13733923 ] Radim Kolar commented on CASSANDRA-5862: Today all new projects should use CRC32C, it can be done in cpu hardware SSE4 and polynomial is improved from crc32. In my test notes Adler32 has 5 times higher collision rate then CRC32, CRC32C is better then CRC32 but very little. Switch to adler checksum for sstables - Key: CASSANDRA-5862 URL: https://issues.apache.org/jira/browse/CASSANDRA-5862 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: T Jake Luciani Fix For: 2.0.1 Attachments: 5862.txt Adler is significantly faster than CRC32: http://java-performance.info/java-crc32-and-adler32/ (Adler is weaker for short inputs, so we should leave the commitlog alone, as it checksums each mutation individually.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5850) change gc_grace_seconds default to 28 days
[ https://issues.apache.org/jira/browse/CASSANDRA-5850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730478#comment-13730478 ] Radim Kolar commented on CASSANDRA-5850: better to do 32 days. If allows schedule repair once per month with cron. change gc_grace_seconds default to 28 days -- Key: CASSANDRA-5850 URL: https://issues.apache.org/jira/browse/CASSANDRA-5850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 beta 2 Reporter: Robert Coli Priority: Trivial Attachments: gc_grace_seconds_to_2419200_seconds_aka_28_days.patch Current default for gc_grace_seconds is 10 days. Attached patch changes all instances of this 10 day default to 28 days. Rationale : - 10 days is arbitrary, there is nothing special about the current value - human societies do not operate on cycles which are a multiple of 10 days, they operate on a cycle of 7 day weeks - operators must run repair once every gc_grace_seconds, and with typical data sizes (and compaction/streaming throttling) this might run for a significant fraction of 10 days - repair often fails, and detecting and working around that failure might also take a significant fraction of 10 days - repair is the heaviest operation one can run on a cassandra cluster and operators are therefore motivated to run it ~3x less frequently by default - the worst case impact is keeping data around for 18 days longer than the previous default, and this only occurs in CFs which actually take DELETE operation - 28 days is an even multiple of 7 days and easily comprehensible as a default time in which to schedule repair -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5727) Evaluate default LCS sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722737#comment-13722737 ] Radim Kolar commented on CASSANDRA-5727: did you tried to measure standard compaction strategy to see if 160 MB LCS brings improvements? Evaluate default LCS sstable size - Key: CASSANDRA-5727 URL: https://issues.apache.org/jira/browse/CASSANDRA-5727 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Daniel Meyer Attachments: BytesRead_vs_LCS.png, ReadLatency_vs_LCS.png, Throughtput_vs_LCS.png, UpdateLatency_vs_LCS.png What we're not sure about is the effect on compaction efficiency -- larger files mean that each level contains more data, so reads will have to touch less sstables, but we're also compacting less unchanged data when we merge forward. So the question is, how big can we make the sstables to get the benefits of the first effect, before the second effect starts to dominate? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5817) shuffle needs some love
Radim Kolar created CASSANDRA-5817: -- Summary: shuffle needs some love Key: CASSANDRA-5817 URL: https://issues.apache.org/jira/browse/CASSANDRA-5817 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 2 Reporter: Radim Kolar Priority: Trivial WARN 10:34:23,046 Token -6470120033327209844 changing ownership from /10.0.0.3 to /10.0.0.1 INFO 10:34:23,046 Flushing memtables for [CFS(Keyspace='system_auth', ColumnFam ily='users')]... INFO 10:34:23,046 RELOCATING: fetching new ranges and streaming old ranges INFO 10:34:23,046 Connecting to /10.0.0.3 for streaming INFO 10:34:23,046 Connecting to /10.0.0.3 for streaming ERROR 10:34:31,750 Streaming error occurred java.lang.NullPointerException at org.apache.cassandra.streaming.ConnectionHandler.sendMessage(Connecti onHandler.java:175) at org.apache.cassandra.streaming.StreamSession.receive(StreamSession.ja va:474) at org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSe ssion.java:361) at org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandl er.run(ConnectionHandler.java:294) at java.lang.Thread.run(Thread.java:724) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5817) shuffle needs some love
[ https://issues.apache.org/jira/browse/CASSANDRA-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13721925#comment-13721925 ] Radim Kolar commented on CASSANDRA-5817: other cassandra has NPE at ConnectionHandler:170 shuffle needs some love --- Key: CASSANDRA-5817 URL: https://issues.apache.org/jira/browse/CASSANDRA-5817 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 2 Reporter: Radim Kolar Priority: Trivial WARN 10:34:23,046 Token -6470120033327209844 changing ownership from /10.0.0.3 to /10.0.0.1 INFO 10:34:23,046 Flushing memtables for [CFS(Keyspace='system_auth', ColumnFam ily='users')]... INFO 10:34:23,046 RELOCATING: fetching new ranges and streaming old ranges INFO 10:34:23,046 Connecting to /10.0.0.3 for streaming INFO 10:34:23,046 Connecting to /10.0.0.3 for streaming ERROR 10:34:31,750 Streaming error occurred java.lang.NullPointerException at org.apache.cassandra.streaming.ConnectionHandler.sendMessage(Connecti onHandler.java:175) at org.apache.cassandra.streaming.StreamSession.receive(StreamSession.ja va:474) at org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSe ssion.java:361) at org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandl er.run(ConnectionHandler.java:294) at java.lang.Thread.run(Thread.java:724) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-5758) Any exception hangs repair
[ https://issues.apache.org/jira/browse/CASSANDRA-5758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar resolved CASSANDRA-5758. Resolution: Won't Fix Any exception hangs repair -- Key: CASSANDRA-5758 URL: https://issues.apache.org/jira/browse/CASSANDRA-5758 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5, 2.0 beta 1 Reporter: Radim Kolar If there is any exception during repair, it hangs and never complete. This is far away from optimal error handling. CASSANDRA-5646 and CASSANDRA-5757 and probably much other issues can be used to reproduce this problem for testing purposes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5758) Any exception hangs repair
[ https://issues.apache.org/jira/browse/CASSANDRA-5758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720234#comment-13720234 ] Radim Kolar commented on CASSANDRA-5758: still not fixed in 2.0b2. But i guess i am just wasting time with this for 1 year. Lets scrap this ticket, you will never agree that exception handling during repair is broken and fix that exception instead of exception handling, right? I am not saying that fixing exception which caused this hang is bad thing. Any exception hangs repair -- Key: CASSANDRA-5758 URL: https://issues.apache.org/jira/browse/CASSANDRA-5758 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5, 2.0 beta 1 Reporter: Radim Kolar If there is any exception during repair, it hangs and never complete. This is far away from optimal error handling. CASSANDRA-5646 and CASSANDRA-5757 and probably much other issues can be used to reproduce this problem for testing purposes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5806) NPE during repair
Radim Kolar created CASSANDRA-5806: -- Summary: NPE during repair Key: CASSANDRA-5806 URL: https://issues.apache.org/jira/browse/CASSANDRA-5806 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 2 Reporter: Radim Kolar Priority: Minor INFO 01:06:00,656 Connecting to /10.0.0.3 for streaming INFO 01:06:00,656 Connecting to /10.0.0.3 for streaming ERROR 01:06:05,828 Streaming error occurred java.lang.NullPointerException at org.apache.cassandra.streaming.ConnectionHandler.sendMessage(Connecti onHandler.java:175) at org.apache.cassandra.streaming.StreamSession.maybeCompleted(StreamSes sion.java:600) at org.apache.cassandra.streaming.StreamSession.prepare(StreamSession.ja va:446) at org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSe ssion.java:357) at org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandl er.run(ConnectionHandler.java:294) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5807) validation failed during repair
Radim Kolar created CASSANDRA-5807: -- Summary: validation failed during repair Key: CASSANDRA-5807 URL: https://issues.apache.org/jira/browse/CASSANDRA-5807 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 2 Reporter: Radim Kolar Priority: Minor INFO 01:05:25,078 [repair #b085cf60-f57e-11e2-981c-c38e7fba9d51] new session: w ill sync /10.0.0.1, /10.0.0.3 on range (-4831857050499933252,-260562612586293613 3] for test.[sipdb] ERROR 01:05:25,078 [repair #aedfc080-f57e-11e2-981c-c38e7fba9d51] session comple ted with the following error org.apache.cassandra.exceptions.RepairException: [repair #aedfc080-f57e-11e2-981 c-c38e7fba9d51 on test/sipdb, (8892198649934659692,-9062237682932646949]] Valida tion failed in /10.0.0.1 at org.apache.cassandra.repair.RepairSession.validationComplete(RepairSe ssion.java:152) at org.apache.cassandra.service.ActiveRepairService.handleMessage(Active RepairService.java:188) at org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMes sageVerbHandler.java:59) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask. java:56) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) + repair hangs (as usual) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5808) repair: sync failed exception
Radim Kolar created CASSANDRA-5808: -- Summary: repair: sync failed exception Key: CASSANDRA-5808 URL: https://issues.apache.org/jira/browse/CASSANDRA-5808 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 2 Reporter: Radim Kolar Priority: Minor this might be just secondary exception caused by something else ERROR 01:54:30,125 Repair session b4fe3820-f57e-11e2-981c-c38e7fba9d51 for range (6833553681770550976,8892198649934659692] failed with error org.apache.cassandr a.exceptions.RepairException: [repair #b4fe3820-f57e-11e2-981c-c38e7fba9d51 on t est/sipdb, (6833553681770550976,8892198649934659692]] Sync failed between /10.0. 0.1 and /10.0.0.3 java.util.concurrent.ExecutionException: java.lang.RuntimeException: org.apache. cassandra.exceptions.RepairException: [repair #b4fe3820-f57e-11e2-981c-c38e7fba9 d51 on test/sipdb, (6833553681770550976,8892198649934659692]] Sync failed betwee n /10.0.0.1 and /10.0.0.3 at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252) at java.util.concurrent.FutureTask.get(FutureTask.java:111) at org.apache.cassandra.service.StorageService$4.runMayThrow(StorageServ ice.java:2400) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:2 8) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:47 1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5809) repair: assert terror
Radim Kolar created CASSANDRA-5809: -- Summary: repair: assert terror Key: CASSANDRA-5809 URL: https://issues.apache.org/jira/browse/CASSANDRA-5809 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 2 Reporter: Radim Kolar and here we have another one! INFO 02:09:40,796 [repair #bd56ab20-f587-11e2-85b0-79ea6f437690] Sending comple ted merkle tree to /10.0.0.3 for test/sipdb ERROR 02:09:41,296 Failed creating a merkle tree for [repair #bdc04260-f587-11e2 -85b0-79ea6f437690 on test/sipdb, (8892198649934659692,-9062237682932646949]], / 10.0.0.3 (see log for details) ERROR 02:09:41,296 Exception in thread Thread[ValidationExecutor:2,1,main] java.lang.AssertionError: -9062226553202808559 is not contained in (889219864993 4659692,-9062237682932646949] at org.apache.cassandra.repair.Validator.add(Validator.java:136) at org.apache.cassandra.db.compaction.CompactionManager.doValidationComp action(CompactionManager.java:669) at org.apache.cassandra.db.compaction.CompactionManager.access$600(Compa ctionManager.java:64) at org.apache.cassandra.db.compaction.CompactionManager$8.call(Compactio nManager.java:395) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5809) repair: assert terror
[ https://issues.apache.org/jira/browse/CASSANDRA-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720278#comment-13720278 ] Radim Kolar commented on CASSANDRA-5809: and yes! it also HANGS! repair: assert terror - Key: CASSANDRA-5809 URL: https://issues.apache.org/jira/browse/CASSANDRA-5809 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 2 Reporter: Radim Kolar and here we have another one! INFO 02:09:40,796 [repair #bd56ab20-f587-11e2-85b0-79ea6f437690] Sending comple ted merkle tree to /10.0.0.3 for test/sipdb ERROR 02:09:41,296 Failed creating a merkle tree for [repair #bdc04260-f587-11e2 -85b0-79ea6f437690 on test/sipdb, (8892198649934659692,-9062237682932646949]], / 10.0.0.3 (see log for details) ERROR 02:09:41,296 Exception in thread Thread[ValidationExecutor:2,1,main] java.lang.AssertionError: -9062226553202808559 is not contained in (889219864993 4659692,-9062237682932646949] at org.apache.cassandra.repair.Validator.add(Validator.java:136) at org.apache.cassandra.db.compaction.CompactionManager.doValidationComp action(CompactionManager.java:669) at org.apache.cassandra.db.compaction.CompactionManager.access$600(Compa ctionManager.java:64) at org.apache.cassandra.db.compaction.CompactionManager$8.call(Compactio nManager.java:395) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5727) Evaluate default LCS sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13709580#comment-13709580 ] Radim Kolar commented on CASSANDRA-5727: You are missing 3 important points. There is no need to read lvldb source code, just read log file and you will notice differences in compaction, which contribute to speedup. I implemented lvldb 3 times. First into HDFS - where metadata are stored into path, second version was improvement of cassandra code, and 3rd version is improved version of current google record based backend, which is leveldb based with modifications allowing it run without filesystem and network part removed + 2 small performance tunings with major effect. You are right about concurrent compactions and non blocking writes for L0. K, you wanted hint, so here it is: Compare L0 in C 2.0 and leveldb. Evaluate default LCS sstable size - Key: CASSANDRA-5727 URL: https://issues.apache.org/jira/browse/CASSANDRA-5727 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Daniel Meyer What we're not sure about is the effect on compaction efficiency -- larger files mean that each level contains more data, so reads will have to touch less sstables, but we're also compacting less unchanged data when we merge forward. So the question is, how big can we make the sstables to get the benefits of the first effect, before the second effect starts to dominate? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5727) Evaluate default LCS sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13709054#comment-13709054 ] Radim Kolar commented on CASSANDRA-5727: Leveldb is using 2MB by default. Real problem is naive leveldb implementation in cassandra. Evaluate default LCS sstable size - Key: CASSANDRA-5727 URL: https://issues.apache.org/jira/browse/CASSANDRA-5727 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Daniel Meyer What we're not sure about is the effect on compaction efficiency -- larger files mean that each level contains more data, so reads will have to touch less sstables, but we're also compacting less unchanged data when we merge forward. So the question is, how big can we make the sstables to get the benefits of the first effect, before the second effect starts to dominate? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5753) cassandra-shuffle is not available for windows
[ https://issues.apache.org/jira/browse/CASSANDRA-5753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13707720#comment-13707720 ] Radim Kolar commented on CASSANDRA-5753: easy to fix. copy cassandra-cli.bat and change name of main class cassandra-shuffle is not available for windows -- Key: CASSANDRA-5753 URL: https://issues.apache.org/jira/browse/CASSANDRA-5753 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 2.0 beta 1 Reporter: Radim Kolar windows version (.BAT file) of cassandra-shuffle utility is missing -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5757) assertionError in repair
Radim Kolar created CASSANDRA-5757: -- Summary: assertionError in repair Key: CASSANDRA-5757 URL: https://issues.apache.org/jira/browse/CASSANDRA-5757 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 2.0 beta 1 Reporter: Radim Kolar i increased replication factor and run repair, some token ranges were repaired okay, but one failed with: INFO 13:03:52,234 [repair #dd7937a0-ebab-11e2-ba07-c38e7fba9d51] session completed successfully ERROR 13:03:52,343 Exception in thread Thread[ValidationExecutor:2,1,main] java.lang.AssertionError: (max(9099058114996150811),max(-5486100704702537010)] at org.apache.cassandra.db.DataRange.init(DataRange.java:50) at org.apache.cassandra.db.DataRange.forKeyRange(DataRange.java:74) at org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReade r.java:1033) at org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScan ners(AbstractCompactionStrategy.java:214) at org.apache.cassandra.db.compaction.CompactionManager$ValidationCompac tionIterable.init(CompactionManager.java:751) at org.apache.cassandra.db.compaction.CompactionManager.doValidationComp action(CompactionManager.java:657) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5758) Any exception hangs repair
Radim Kolar created CASSANDRA-5758: -- Summary: Any exception hangs repair Key: CASSANDRA-5758 URL: https://issues.apache.org/jira/browse/CASSANDRA-5758 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 2.0 beta 1, 1.2.5 Reporter: Radim Kolar If there is any exception during repair, it hangs and never complete. This is far away from optimal error handling. CASSANDRA-5646 and CASSANDRA-5757 and probably much other issues can be used to reproduce this problem for testing purposes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5758) Any exception hangs repair
[ https://issues.apache.org/jira/browse/CASSANDRA-5758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13707863#comment-13707863 ] Radim Kolar commented on CASSANDRA-5758: Actually any time I see exception during repair then repair hangs and you can not run other repair until you restart node. if you want example for 2.0 then CASSANDRA-5757 hangs repair. Any exception hangs repair -- Key: CASSANDRA-5758 URL: https://issues.apache.org/jira/browse/CASSANDRA-5758 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5, 2.0 beta 1 Reporter: Radim Kolar If there is any exception during repair, it hangs and never complete. This is far away from optimal error handling. CASSANDRA-5646 and CASSANDRA-5757 and probably much other issues can be used to reproduce this problem for testing purposes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5753) cassandra-shuffle is not available for windows
Radim Kolar created CASSANDRA-5753: -- Summary: cassandra-shuffle is not available for windows Key: CASSANDRA-5753 URL: https://issues.apache.org/jira/browse/CASSANDRA-5753 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 2.0 beta 1 Reporter: Radim Kolar windows version (.BAT file) of cassandra-shuffle utility is missing -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5755) shuffle clear fails
Radim Kolar created CASSANDRA-5755: -- Summary: shuffle clear fails Key: CASSANDRA-5755 URL: https://issues.apache.org/jira/browse/CASSANDRA-5755 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 2.0 beta 1 Reporter: Radim Kolar C:\cassandra2\binshuffle.bat clear Exception in thread main java.lang.RuntimeException: InvalidRequestException(why:Invalid STRING constant (ee7f3e119820c96d) for token_bytes of type blob) at org.apache.cassandra.tools.Shuffle.executeCqlQuery(Shuffle.java:516) at org.apache.cassandra.tools.Shuffle.clear(Shuffle.java:439) at org.apache.cassandra.tools.Shuffle.main(Shuffle.java:689) Caused by: InvalidRequestException(why:Invalid STRING constant (ee7f3e119820c96d ) for token_bytes of type blob) at org.apache.cassandra.thrift.Cassandra$execute_cql3_query_result$execu te_cql3_query_resultStandardScheme.read(Cassandra.java:45153) at org.apache.cassandra.thrift.Cassandra$execute_cql3_query_result$execu te_cql3_query_resultStandardScheme.read(Cassandra.java:45130) at org.apache.cassandra.thrift.Cassandra$execute_cql3_query_result.read( -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5756) shuffle disable subcommand not recognised
Radim Kolar created CASSANDRA-5756: -- Summary: shuffle disable subcommand not recognised Key: CASSANDRA-5756 URL: https://issues.apache.org/jira/browse/CASSANDRA-5756 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 2.0 beta 1 Reporter: Radim Kolar command disable listed in help but not recognized C:\cassandra2\binshuffle.bat disable Unknown subcommand: disable Usage: shuffle [options] sub-command Sub-commands: create Initialize a new shuffle operation ls List pending relocations clearClear pending relocations en[able] Enable shuffling dis[able]Disable shuffling -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5646) Incompatible sstables hangs repair
[ https://issues.apache.org/jira/browse/CASSANDRA-5646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685103#comment-13685103 ] Radim Kolar commented on CASSANDRA-5646: Problem is that error handling in repair so bad that practically any exception hangs it Incompatible sstables hangs repair -- Key: CASSANDRA-5646 URL: https://issues.apache.org/jira/browse/CASSANDRA-5646 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Radim Kolar repair session between 1.2.5 and 1.2.4: ERROR [Thread-11] 2013-06-16 13:39:39,359 CassandraDaemon.java (line 175) Exception in thread Thread[Thread-11,5,main] java.lang.UnsupportedOperationException: SSTable C:\Program Files (x86)\DataStax Community\data\data\test\sipdb\test-sipdb-hf-16-Data.db is not compatible with current version ic at org.apache.cassandra.streaming.StreamIn.getContextMapping(StreamIn.java:77) at org.apache.cassandra.streaming.IncomingStreamReader.init(IncomingStreamReader.java:87) at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238) at org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78) using nodetool netstats shows both sstables streaming at 0/XX. repair never finished. After upgrading sstables to latest level (hf and ic should be compatible) repair works fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5646) Incompatible sstables hangs repair
Radim Kolar created CASSANDRA-5646: -- Summary: Incompatible sstables hangs repair Key: CASSANDRA-5646 URL: https://issues.apache.org/jira/browse/CASSANDRA-5646 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Radim Kolar repair session between 1.2.5 and 1.2.4: ERROR [Thread-11] 2013-06-16 13:39:39,359 CassandraDaemon.java (line 175) Exception in thread Thread[Thread-11,5,main] java.lang.UnsupportedOperationException: SSTable C:\Program Files (x86)\DataStax Community\data\data\test\sipdb\test-sipdb-hf-16-Data.db is not compatible with current version ic at org.apache.cassandra.streaming.StreamIn.getContextMapping(StreamIn.java:77) at org.apache.cassandra.streaming.IncomingStreamReader.init(IncomingStreamReader.java:87) at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238) at org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78) using nodetool netstats shows both sstables streaming at 0/XX. repair never finished. After upgrading sstables to latest level (hf and ic should be compatible) repair works fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5646) Incompatible sstables hangs repair
[ https://issues.apache.org/jira/browse/CASSANDRA-5646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684713#comment-13684713 ] Radim Kolar commented on CASSANDRA-5646: should not be 1.2 able to read 1.1.X? Incompatible sstables hangs repair -- Key: CASSANDRA-5646 URL: https://issues.apache.org/jira/browse/CASSANDRA-5646 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Radim Kolar repair session between 1.2.5 and 1.2.4: ERROR [Thread-11] 2013-06-16 13:39:39,359 CassandraDaemon.java (line 175) Exception in thread Thread[Thread-11,5,main] java.lang.UnsupportedOperationException: SSTable C:\Program Files (x86)\DataStax Community\data\data\test\sipdb\test-sipdb-hf-16-Data.db is not compatible with current version ic at org.apache.cassandra.streaming.StreamIn.getContextMapping(StreamIn.java:77) at org.apache.cassandra.streaming.IncomingStreamReader.init(IncomingStreamReader.java:87) at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238) at org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78) using nodetool netstats shows both sstables streaming at 0/XX. repair never finished. After upgrading sstables to latest level (hf and ic should be compatible) repair works fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3741) OOMs because delete operations are not accounted
[ https://issues.apache.org/jira/browse/CASSANDRA-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13663802#comment-13663802 ] Radim Kolar commented on CASSANDRA-3741: i retested it. bug from 1.0 do not exists in 1.1 and 1.2. But its still not optimal and can lead to OOM because it do not adds enough bytes count for tombstone to live data count. If i remember some hardcoded constant was used, it needs to be raised. OOMs because delete operations are not accounted Key: CASSANDRA-3741 URL: https://issues.apache.org/jira/browse/CASSANDRA-3741 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: FreeBSD Reporter: Vitalii Tymchyshyn Assignee: Andriy Kolyadenko Fix For: 1.1.1 Currently we are moving to new data format where new format is written into new CFs and old one is deleted key-by-key. I have started getting OOMs and found out that delete operations are not accounted and so, column families are not flushed (changed == 0 with delete only operations) by storage manager. This is pull request that fixed this problem for me: https://github.com/apache/cassandra/pull/5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5473) Use mmaped buffered write for ldb segments
Radim Kolar created CASSANDRA-5473: -- Summary: Use mmaped buffered write for ldb segments Key: CASSANDRA-5473 URL: https://issues.apache.org/jira/browse/CASSANDRA-5473 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar it increases throughput, especially in compations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5473) Use mmaped buffered write for ldb segments
[ https://issues.apache.org/jira/browse/CASSANDRA-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-5473: --- Attachment: leveldb.ods write only workload benchmark. Use mmaped buffered write for ldb segments -- Key: CASSANDRA-5473 URL: https://issues.apache.org/jira/browse/CASSANDRA-5473 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Labels: performance Attachments: leveldb.ods it increases throughput, especially in compations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5473) Use mmaped buffered write for ldb segments
[ https://issues.apache.org/jira/browse/CASSANDRA-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632037#comment-13632037 ] Radim Kolar commented on CASSANDRA-5473: yes, every line in one test run to check variations between runs. Use mmaped buffered write for ldb segments -- Key: CASSANDRA-5473 URL: https://issues.apache.org/jira/browse/CASSANDRA-5473 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Labels: performance Attachments: leveldb.ods it increases throughput, especially in compations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5473) Use mmaped buffered write for ldb segments
[ https://issues.apache.org/jira/browse/CASSANDRA-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632044#comment-13632044 ] Radim Kolar commented on CASSANDRA-5473: i have not checked other patch code but you have to create file part, mmap it, write to memory, unmap, enlarge file, mmap next segment, write, unmap and truncate file to desired size. Use mmaped buffered write for ldb segments -- Key: CASSANDRA-5473 URL: https://issues.apache.org/jira/browse/CASSANDRA-5473 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Labels: performance Attachments: leveldb.ods it increases throughput, especially in compations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541608#comment-13541608 ] Radim Kolar commented on CASSANDRA-4897: Everything configured incorrectly will drop performance. Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Assignee: Radim Kolar Fix For: 1.2.1 Attachments: cass-maxsize1.txt, cass-maxsize2.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4707) EOFException during HH delivery
[ https://issues.apache.org/jira/browse/CASSANDRA-4707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar resolved CASSANDRA-4707. Resolution: Invalid works fine EOFException during HH delivery --- Key: CASSANDRA-4707 URL: https://issues.apache.org/jira/browse/CASSANDRA-4707 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Environment: windows Reporter: Radim Kolar i have got following error during HH every replay. I did nodetool scrub on system.hintedhandoff and sstable is not corrupted, it must have invalid data inside. INFO [HintedHandoff:10] 2012-09-23 20:26:21,988 HintedHandOffManager.java (line 294) Started hinted handoff for token: 138224439286689469893643387845607487221 with IP: /10.0.0.9 ERROR [HintedHandoff:10] 2012-09-23 20:26:21,988 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[HintedHandoff:10,1,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:259) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:275) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:232) at edu.stanford.ppl.concurrent.SnapTreeMap.init(SnapTreeMap.java:453) at org.apache.cassandra.db.AtomicSortedColumns$Holder.init(AtomicSortedColumns.java:311) at org.apache.cassandra.db.AtomicSortedColumns.init(AtomicSortedColumns.java:77) at org.apache.cassandra.db.AtomicSortedColumns.init(AtomicSortedColumns.java:48) at org.apache.cassandra.db.AtomicSortedColumns$1.fromSorted(AtomicSortedColumns.java:61) at org.apache.cassandra.db.SuperColumnSerializer.deserialize(SuperColumn.java:399) at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:144) at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:136) at org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:129) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:439) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:447) at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:353) at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:256) at org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:84) at org.apache.cassandra.db.HintedHandOffManager$3.runMayThrow(HintedHandOffManager.java:436) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.io.EOFException at java.io.DataInputStream.readFully(DataInputStream.java:197) at java.io.DataInputStream.readFully(DataInputStream.java:169) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:401) at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:380) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:88) at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:255) ... 21 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537296#comment-13537296 ] Radim Kolar commented on CASSANDRA-4897: You are right in both cases. There needs to be some kind of heuristics when to compact bucket with max sized tables. I have to take a look at lucene code, but it has way more elaborated tiered compaction (not bucket based). Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Assignee: Radim Kolar Fix For: 1.2.1 Attachments: cass-maxsize1.txt, cass-maxsize2.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537347#comment-13537347 ] Radim Kolar commented on CASSANDRA-4897: I am thinking about checking sstables timestamps in largest bucket. If oldest table is older then user configured number of hours, then run compaction. Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Assignee: Radim Kolar Fix For: 1.2.1 Attachments: cass-maxsize1.txt, cass-maxsize2.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3961) Make index_interval configurable per column family
[ https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13527161#comment-13527161 ] Radim Kolar commented on CASSANDRA-3961: can it go into 1.2? its simple patch. Make index_interval configurable per column family -- Key: CASSANDRA-3961 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961 Project: Cassandra Issue Type: Improvement Components: Core Environment: Cassandra 1.0.7/unix Reporter: Radim Kolar Assignee: Radim Kolar Fix For: 2.0 Attachments: cass-interval1.txt, cass-interval2.txt, cass-interval3.txt, cass-interval4.txt, cass-interval5.txt, cass-interval6.txt After various experiments with mixing OLTP a OLAP workload running on single cassandra cluster i discovered that lot of memory is wasted on holding index samples for CF which are rarely accessed or index is not much used for CF access because slices over keys are used. There is per column family setting for configuring bloom filters - bloom_filter_fp_chance. Please add setting index_interval configurable per CF as well. If this setting is not set or it is zero, default from cassandra.yaml will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13527007#comment-13527007 ] Radim Kolar commented on CASSANDRA-4897: v2 patch is not useful for anything except splitting large sstables. Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Attachments: cass-maxsize1.txt, cass-maxsize2.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4891) support for running findbugs
[ https://issues.apache.org/jira/browse/CASSANDRA-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502840#comment-13502840 ] Radim Kolar commented on CASSANDRA-4891: it cost you nothing to have it in ant buildfile. support for running findbugs Key: CASSANDRA-4891 URL: https://issues.apache.org/jira/browse/CASSANDRA-4891 Project: Cassandra Issue Type: Improvement Components: Tests Affects Versions: 1.3 Reporter: Radim Kolar Attachments: cass-findbugs.txt add findbugs target to ant task -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3662) Report memory used by row index samples
[ https://issues.apache.org/jira/browse/CASSANDRA-3662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar resolved CASSANDRA-3662. Resolution: Not A Problem i already did that myself. Report memory used by row index samples --- Key: CASSANDRA-3662 URL: https://issues.apache.org/jira/browse/CASSANDRA-3662 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.8.9, 1.0.6 Reporter: Radim Kolar Priority: Minor For better memory tuning on nodes with huge number of rows in CF, it will be good to know how much memory is used by entries collected during index sampling. This will allow user to fine tune _index_interval_ Proposed output as addition to nodetool cfstats Column Family: sipdb SSTable count: 13 Space used (live): 27378331692 Space used (total): 27378331692 Number of Keys (estimate): 216613000 *Sampled index entries: 433226* *Memory used by sampled index: 51987120* -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3961) Make index_interval configurable per column family
[ https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-3961: --- Attachment: cass-interval5.txt Make index_interval configurable per column family -- Key: CASSANDRA-3961 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961 Project: Cassandra Issue Type: Improvement Components: Core Environment: Cassandra 1.0.7/unix Reporter: Radim Kolar Assignee: Radim Kolar Fix For: 1.3 Attachments: cass-interval1.txt, cass-interval2.txt, cass-interval3.txt, cass-interval4.txt, cass-interval5.txt After various experiments with mixing OLTP a OLAP workload running on single cassandra cluster i discovered that lot of memory is wasted on holding index samples for CF which are rarely accessed or index is not much used for CF access because slices over keys are used. There is per column family setting for configuring bloom filters - bloom_filter_fp_chance. Please add setting index_interval configurable per CF as well. If this setting is not set or it is zero, default from cassandra.yaml will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3961) Make index_interval configurable per column family
[ https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-3961: --- Attachment: cass-interval6.txt some extra whitespace cleaned Make index_interval configurable per column family -- Key: CASSANDRA-3961 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961 Project: Cassandra Issue Type: Improvement Components: Core Environment: Cassandra 1.0.7/unix Reporter: Radim Kolar Assignee: Radim Kolar Fix For: 1.3 Attachments: cass-interval1.txt, cass-interval2.txt, cass-interval3.txt, cass-interval4.txt, cass-interval5.txt, cass-interval6.txt After various experiments with mixing OLTP a OLAP workload running on single cassandra cluster i discovered that lot of memory is wasted on holding index samples for CF which are rarely accessed or index is not much used for CF access because slices over keys are used. There is per column family setting for configuring bloom filters - bloom_filter_fp_chance. Please add setting index_interval configurable per CF as well. If this setting is not set or it is zero, default from cassandra.yaml will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3961) Make index_interval configurable per column family
[ https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502998#comment-13502998 ] Radim Kolar commented on CASSANDRA-3961: your review is wrong. #3 is done by load(boolean) Make index_interval configurable per column family -- Key: CASSANDRA-3961 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961 Project: Cassandra Issue Type: Improvement Components: Core Environment: Cassandra 1.0.7/unix Reporter: Radim Kolar Assignee: Radim Kolar Fix For: 1.3 Attachments: cass-interval1.txt, cass-interval2.txt, cass-interval3.txt, cass-interval4.txt, cass-interval5.txt, cass-interval6.txt After various experiments with mixing OLTP a OLAP workload running on single cassandra cluster i discovered that lot of memory is wasted on holding index samples for CF which are rarely accessed or index is not much used for CF access because slices over keys are used. There is per column family setting for configuring bloom filters - bloom_filter_fp_chance. Please add setting index_interval configurable per CF as well. If this setting is not set or it is zero, default from cassandra.yaml will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501924#comment-13501924 ] Radim Kolar commented on CASSANDRA-4897: it was fixed in patch version 2. Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Attachments: cass-maxsize1.txt, cass-maxsize2.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4899) add gitignore
[ https://issues.apache.org/jira/browse/CASSANDRA-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501990#comment-13501990 ] Radim Kolar commented on CASSANDRA-4899: .gitignore in tree is stardard used by pretty much every project. If somebody would like to get some more files ignored (like for IDEA IDE which i do not have) then he can submit patch. Its still less work then writing .gitignore by hand everytime you run checkout. add gitignore - Key: CASSANDRA-4899 URL: https://issues.apache.org/jira/browse/CASSANDRA-4899 Project: Cassandra Issue Type: Task Reporter: Radim Kolar Assignee: Radim Kolar Priority: Trivial Attachments: cass-gitignore.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4899) add gitignore
[ https://issues.apache.org/jira/browse/CASSANDRA-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502484#comment-13502484 ] Radim Kolar commented on CASSANDRA-4899: If you do not want to commit this then close it, so i do not have to keep this in mind. add gitignore - Key: CASSANDRA-4899 URL: https://issues.apache.org/jira/browse/CASSANDRA-4899 Project: Cassandra Issue Type: Task Reporter: Radim Kolar Assignee: Radim Kolar Priority: Trivial Attachments: cass-gitignore.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4891) support for running findbugs
[ https://issues.apache.org/jira/browse/CASSANDRA-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501496#comment-13501496 ] Radim Kolar commented on CASSANDRA-4891: because currently is eclipse findbugs plugin broken in E4.2, while it is fixed in repository, its not released yet and its in soon status for about 8 months. I would not count on it. support for running findbugs Key: CASSANDRA-4891 URL: https://issues.apache.org/jira/browse/CASSANDRA-4891 Project: Cassandra Issue Type: Improvement Components: Tests Affects Versions: 1.3 Reporter: Radim Kolar Attachments: cass-findbugs.txt add findbugs target to ant task -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4899) add gitignore
[ https://issues.apache.org/jira/browse/CASSANDRA-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501627#comment-13501627 ] Radim Kolar commented on CASSANDRA-4899: can be this committed? its highly annoying to work with git extensions because it shows 2798 uncommitted files. add gitignore - Key: CASSANDRA-4899 URL: https://issues.apache.org/jira/browse/CASSANDRA-4899 Project: Cassandra Issue Type: Task Reporter: Radim Kolar Assignee: Radim Kolar Attachments: cass-gitignore.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3961) Make index_interval configurable per column family
[ https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-3961: --- Attachment: cass-interval3.txt Make index_interval configurable per column family -- Key: CASSANDRA-3961 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961 Project: Cassandra Issue Type: Improvement Components: Core Environment: Cassandra 1.0.7/unix Reporter: Radim Kolar Assignee: Radim Kolar Fix For: 1.3 Attachments: cass-interval1.txt, cass-interval2.txt, cass-interval3.txt After various experiments with mixing OLTP a OLAP workload running on single cassandra cluster i discovered that lot of memory is wasted on holding index samples for CF which are rarely accessed or index is not much used for CF access because slices over keys are used. There is per column family setting for configuring bloom filters - bloom_filter_fp_chance. Please add setting index_interval configurable per CF as well. If this setting is not set or it is zero, default from cassandra.yaml will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3961) Make index_interval configurable per column family
[ https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-3961: --- Attachment: cass-interval4.txt Make index_interval configurable per column family -- Key: CASSANDRA-3961 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961 Project: Cassandra Issue Type: Improvement Components: Core Environment: Cassandra 1.0.7/unix Reporter: Radim Kolar Assignee: Radim Kolar Fix For: 1.3 Attachments: cass-interval1.txt, cass-interval2.txt, cass-interval3.txt, cass-interval4.txt After various experiments with mixing OLTP a OLAP workload running on single cassandra cluster i discovered that lot of memory is wasted on holding index samples for CF which are rarely accessed or index is not much used for CF access because slices over keys are used. There is per column family setting for configuring bloom filters - bloom_filter_fp_chance. Please add setting index_interval configurable per CF as well. If this setting is not set or it is zero, default from cassandra.yaml will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-4897: --- Attachment: cass-maxsize2.txt do not compact bucket with maximum sized tables. Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Attachments: cass-maxsize1.txt, cass-maxsize2.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490729#comment-13490729 ] Radim Kolar commented on CASSANDRA-4897: this one is very trivial, you can fix it yourself. Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Assignee: Radim Kolar Attachments: cass-maxsize1.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar reassigned CASSANDRA-4897: -- Assignee: (was: Radim Kolar) Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Attachments: cass-maxsize1.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3961) Make index_interval configurable per column family
[ https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-3961: --- Attachment: cass-interval2.txt Make index_interval configurable per column family -- Key: CASSANDRA-3961 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.7 Environment: Cassandra 1.0.7/unix Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Attachments: cass-interval1.txt, cass-interval2.txt After various experiments with mixing OLTP a OLAP workload running on single cassandra cluster i discovered that lot of memory is wasted on holding index samples for CF which are rarely accessed or index is not much used for CF access because slices over keys are used. There is per column family setting for configuring bloom filters - bloom_filter_fp_chance. Please add setting index_interval configurable per CF as well. If this setting is not set or it is zero, default from cassandra.yaml will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3961) Make index_interval configurable per column family
[ https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-3961: --- Component/s: Core Priority: Major (was: Minor) Affects Version/s: (was: 1.0.7) 1.2.0 beta 1 Make index_interval configurable per column family -- Key: CASSANDRA-3961 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.0 beta 1 Environment: Cassandra 1.0.7/unix Reporter: Radim Kolar Assignee: Radim Kolar Attachments: cass-interval1.txt, cass-interval2.txt After various experiments with mixing OLTP a OLAP workload running on single cassandra cluster i discovered that lot of memory is wasted on holding index samples for CF which are rarely accessed or index is not much used for CF access because slices over keys are used. There is per column family setting for configuring bloom filters - bloom_filter_fp_chance. Please add setting index_interval configurable per CF as well. If this setting is not set or it is zero, default from cassandra.yaml will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar reassigned CASSANDRA-4897: -- Assignee: Radim Kolar Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Assignee: Radim Kolar Attachments: cass-maxsize1.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-4897: --- Attachment: cass-maxsize1.txt Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Assignee: Radim Kolar Attachments: cass-maxsize1.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4896) Upgrade thrift to 0.9.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489388#comment-13489388 ] Radim Kolar commented on CASSANDRA-4896: Thrift you are using has known memory leaks, some are fixed in 0.9. Can you explain benefits for end user to have intentionally delivered software with memory leaks? Upgrade thrift to 0.9.0 --- Key: CASSANDRA-4896 URL: https://issues.apache.org/jira/browse/CASSANDRA-4896 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Attachments: cass-thrift09.txt, libthrift-0.9.0.jar, thrift-python-internal-only-0.9.0.zip -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4896) Upgrade thrift to 0.9.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489453#comment-13489453 ] Radim Kolar commented on CASSANDRA-4896: There are no memory leak fixes committed to github after 0.9.0 was released. Closer inspection of thrift changelog shows that memory leaks fixed in 0.8 and 0.9 are not related to java server, but to C/C++. Interesting fix is THRIFT-1457 for shrinking memory buffers. Upgrade thrift to 0.9.0 --- Key: CASSANDRA-4896 URL: https://issues.apache.org/jira/browse/CASSANDRA-4896 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Attachments: cass-thrift09.txt, libthrift-0.9.0.jar, thrift-python-internal-only-0.9.0.zip -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4896) Upgrade thrift to 0.9.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489472#comment-13489472 ] Radim Kolar commented on CASSANDRA-4896: its not but since patch is trivial and you ship thrift library binary with cassandra, you can ship a patched one. Upgrade thrift to 0.9.0 --- Key: CASSANDRA-4896 URL: https://issues.apache.org/jira/browse/CASSANDRA-4896 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Attachments: cass-thrift09.txt, libthrift-0.9.0.jar, thrift-python-internal-only-0.9.0.zip -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4899) add gitignore
Radim Kolar created CASSANDRA-4899: -- Summary: add gitignore Key: CASSANDRA-4899 URL: https://issues.apache.org/jira/browse/CASSANDRA-4899 Project: Cassandra Issue Type: Task Reporter: Radim Kolar Assignee: Radim Kolar Attachments: cass-gitignore.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4899) add gitignore
[ https://issues.apache.org/jira/browse/CASSANDRA-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-4899: --- Attachment: cass-gitignore.txt add gitignore - Key: CASSANDRA-4899 URL: https://issues.apache.org/jira/browse/CASSANDRA-4899 Project: Cassandra Issue Type: Task Reporter: Radim Kolar Assignee: Radim Kolar Attachments: cass-gitignore.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3961) Make index_interval configurable per column family
[ https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-3961: --- Attachment: cass-interval1.txt Make index_interval configurable per column family -- Key: CASSANDRA-3961 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.7 Environment: Cassandra 1.0.7/unix Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Attachments: cass-interval1.txt After various experiments with mixing OLTP a OLAP workload running on single cassandra cluster i discovered that lot of memory is wasted on holding index samples for CF which are rarely accessed or index is not much used for CF access because slices over keys are used. There is per column family setting for configuring bloom filters - bloom_filter_fp_chance. Please add setting index_interval configurable per CF as well. If this setting is not set or it is zero, default from cassandra.yaml will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4889) Code cleanup against JDK 1.6 codestyle guide
[ https://issues.apache.org/jira/browse/CASSANDRA-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488594#comment-13488594 ] Radim Kolar commented on CASSANDRA-4889: alright, if you dont like hamcrest. I will regenerate this with hamcrest disabled. What about adding missing @Override? Code cleanup against JDK 1.6 codestyle guide Key: CASSANDRA-4889 URL: https://issues.apache.org/jira/browse/CASSANDRA-4889 Project: Cassandra Issue Type: Bug Affects Versions: 1.3 Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Labels: codestyle Attachments: cass-cleanup1.txt Code cleanup against jdk1.6 ruleset on lowest settings. problems fixed: extra ; unused imports incorrect if (condition is always true or always false) using static variable in non static way always true asserts -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4889) Code cleanup against JDK 1.6 codestyle guide
[ https://issues.apache.org/jira/browse/CASSANDRA-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488631#comment-13488631 ] Radim Kolar commented on CASSANDRA-4889: your custom @override policy is not supported by my tool, patch regenerated and constant assert moved to unit test. Code cleanup against JDK 1.6 codestyle guide Key: CASSANDRA-4889 URL: https://issues.apache.org/jira/browse/CASSANDRA-4889 Project: Cassandra Issue Type: Bug Affects Versions: 1.3 Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Labels: codestyle Attachments: cass-cleanup1.txt, cass-cleanup2.txt Code cleanup against jdk1.6 ruleset on lowest settings. problems fixed: extra ; unused imports incorrect if (condition is always true or always false) using static variable in non static way always true asserts -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4889) Code cleanup against JDK 1.6 codestyle guide
[ https://issues.apache.org/jira/browse/CASSANDRA-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-4889: --- Attachment: cass-cleanup2.txt Code cleanup against JDK 1.6 codestyle guide Key: CASSANDRA-4889 URL: https://issues.apache.org/jira/browse/CASSANDRA-4889 Project: Cassandra Issue Type: Bug Affects Versions: 1.3 Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Labels: codestyle Attachments: cass-cleanup1.txt, cass-cleanup2.txt Code cleanup against jdk1.6 ruleset on lowest settings. problems fixed: extra ; unused imports incorrect if (condition is always true or always false) using static variable in non static way always true asserts -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4891) support for running findbugs
Radim Kolar created CASSANDRA-4891: -- Summary: support for running findbugs Key: CASSANDRA-4891 URL: https://issues.apache.org/jira/browse/CASSANDRA-4891 Project: Cassandra Issue Type: Improvement Components: Tests Affects Versions: 1.3 Reporter: Radim Kolar add findbugs target to ant task -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4891) support for running findbugs
[ https://issues.apache.org/jira/browse/CASSANDRA-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-4891: --- Attachment: cass-findbugs.txt support for running findbugs Key: CASSANDRA-4891 URL: https://issues.apache.org/jira/browse/CASSANDRA-4891 Project: Cassandra Issue Type: Improvement Components: Tests Affects Versions: 1.3 Reporter: Radim Kolar Attachments: cass-findbugs.txt add findbugs target to ant task -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4891) support for running findbugs
[ https://issues.apache.org/jira/browse/CASSANDRA-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488731#comment-13488731 ] Radim Kolar commented on CASSANDRA-4891: Interesting part of findbugs report is incorrect unlocking in org.apache.cassandra.db.compaction.CompactionManager. findbugs is still not in class with pro tools doing run-time analysis, findbugs can't find cause of CASSANDRA-4687 while commercial tools can. support for running findbugs Key: CASSANDRA-4891 URL: https://issues.apache.org/jira/browse/CASSANDRA-4891 Project: Cassandra Issue Type: Improvement Components: Tests Affects Versions: 1.3 Reporter: Radim Kolar Attachments: cass-findbugs.txt add findbugs target to ant task -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4896) Upgrade thrift to 0.9.0
Radim Kolar created CASSANDRA-4896: -- Summary: Upgrade thrift to 0.9.0 Key: CASSANDRA-4896 URL: https://issues.apache.org/jira/browse/CASSANDRA-4896 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Attachments: libthrift-0.9.0.jar, thrift-python-internal-only-0.9.0.zip -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4896) Upgrade thrift to 0.9.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-4896: --- Attachment: thrift-python-internal-only-0.9.0.zip libthrift-0.9.0.jar Upgrade thrift to 0.9.0 --- Key: CASSANDRA-4896 URL: https://issues.apache.org/jira/browse/CASSANDRA-4896 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Attachments: libthrift-0.9.0.jar, thrift-python-internal-only-0.9.0.zip -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4896) Upgrade thrift to 0.9.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-4896: --- Attachment: cass-thrift09.txt Upgrade thrift to 0.9.0 --- Key: CASSANDRA-4896 URL: https://issues.apache.org/jira/browse/CASSANDRA-4896 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Attachments: cass-thrift09.txt, libthrift-0.9.0.jar, thrift-python-internal-only-0.9.0.zip -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4889) Code cleanup against JDK 1.6 codestyle guide
[ https://issues.apache.org/jira/browse/CASSANDRA-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489195#comment-13489195 ] Radim Kolar commented on CASSANDRA-4889: assert is for runtime checking, unit tests are for catching errors caused by code changes. Code cleanup against JDK 1.6 codestyle guide Key: CASSANDRA-4889 URL: https://issues.apache.org/jira/browse/CASSANDRA-4889 Project: Cassandra Issue Type: Bug Affects Versions: 1.3 Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Labels: codestyle Attachments: cass-cleanup1.txt, cass-cleanup2.txt Code cleanup against jdk1.6 ruleset on lowest settings. problems fixed: extra ; unused imports incorrect if (condition is always true or always false) using static variable in non static way always true asserts -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3961) Make index_interval configurable per column family
[ https://issues.apache.org/jira/browse/CASSANDRA-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar reassigned CASSANDRA-3961: -- Assignee: Radim Kolar Make index_interval configurable per column family -- Key: CASSANDRA-3961 URL: https://issues.apache.org/jira/browse/CASSANDRA-3961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.7 Environment: Cassandra 1.0.7/unix Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor After various experiments with mixing OLTP a OLAP workload running on single cassandra cluster i discovered that lot of memory is wasted on holding index samples for CF which are rarely accessed or index is not much used for CF access because slices over keys are used. There is per column family setting for configuring bloom filters - bloom_filter_fp_chance. Please add setting index_interval configurable per CF as well. If this setting is not set or it is zero, default from cassandra.yaml will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4897) Allow tiered compaction define max sstable size
Radim Kolar created CASSANDRA-4897: -- Summary: Allow tiered compaction define max sstable size Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4889) Code cleanup against JDK 1.6 codestyle guide
Radim Kolar created CASSANDRA-4889: -- Summary: Code cleanup against JDK 1.6 codestyle guide Key: CASSANDRA-4889 URL: https://issues.apache.org/jira/browse/CASSANDRA-4889 Project: Cassandra Issue Type: Bug Affects Versions: 1.3 Reporter: Radim Kolar Priority: Minor Attachments: cass-cleanup1.txt Code cleanup against jdk1.6 ruleset on lowest settings. problems fixed: extra ; unused imports incorrect if (condition is always true or always false) using static variable in non static way always true asserts -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4889) Code cleanup against JDK 1.6 codestyle guide
[ https://issues.apache.org/jira/browse/CASSANDRA-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-4889: --- Attachment: cass-cleanup1.txt Code cleanup against JDK 1.6 codestyle guide Key: CASSANDRA-4889 URL: https://issues.apache.org/jira/browse/CASSANDRA-4889 Project: Cassandra Issue Type: Bug Affects Versions: 1.3 Reporter: Radim Kolar Priority: Minor Labels: codestyle Attachments: cass-cleanup1.txt Code cleanup against jdk1.6 ruleset on lowest settings. problems fixed: extra ; unused imports incorrect if (condition is always true or always false) using static variable in non static way always true asserts -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4889) Code cleanup against JDK 1.6 codestyle guide
[ https://issues.apache.org/jira/browse/CASSANDRA-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488371#comment-13488371 ] Radim Kolar commented on CASSANDRA-4889: findbugs discovered problems are not included because findbugs crash after finding about 500 problems. Code cleanup against JDK 1.6 codestyle guide Key: CASSANDRA-4889 URL: https://issues.apache.org/jira/browse/CASSANDRA-4889 Project: Cassandra Issue Type: Bug Affects Versions: 1.3 Reporter: Radim Kolar Priority: Minor Labels: codestyle Attachments: cass-cleanup1.txt Code cleanup against jdk1.6 ruleset on lowest settings. problems fixed: extra ; unused imports incorrect if (condition is always true or always false) using static variable in non static way always true asserts -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4777) Hint delivery blocks compactions
[ https://issues.apache.org/jira/browse/CASSANDRA-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13485508#comment-13485508 ] Radim Kolar commented on CASSANDRA-4777: no Hint delivery blocks compactions Key: CASSANDRA-4777 URL: https://issues.apache.org/jira/browse/CASSANDRA-4777 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.12 Reporter: Radim Kolar If there is hint delivery in progress, then compaction of hints table is blocked at 100% and other sstables can not be compacted. ponto:(admin)~nodetool -h localhost compactionstats pending tasks: 4542 compaction typekeyspace column family bytes compacted bytes total progress Compaction systemHintsColumnFamily80833566 80833566 100.00% ponto:(admin)~nodetool -h localhost tpstats Pool NameActive Pending Completed Blocked All time blocked HintedHandoff 1 1 55 0 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4777) Hint delivery blocks compactions
Radim Kolar created CASSANDRA-4777: -- Summary: Hint delivery blocks compactions Key: CASSANDRA-4777 URL: https://issues.apache.org/jira/browse/CASSANDRA-4777 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.12 Reporter: Radim Kolar If there is hint delivery in progress, then compaction of hints table is blocked at 100% and other sstables can not be compacted. ponto:(admin)~nodetool -h localhost compactionstats pending tasks: 4542 compaction typekeyspace column family bytes compacted bytes total progress Compaction systemHintsColumnFamily80833566 80833566 100.00% ponto:(admin)~nodetool -h localhost tpstats Pool NameActive Pending Completed Blocked All time blocked HintedHandoff 1 1 55 0 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4701) get ends with unknown CF exception
[ https://issues.apache.org/jira/browse/CASSANDRA-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463633#comment-13463633 ] Radim Kolar commented on CASSANDRA-4701: Its related to CASSANDRA-4707, its from same test run. Our cassandra testsuite can reproduce both. get ends with unknown CF exception -- Key: CASSANDRA-4701 URL: https://issues.apache.org/jira/browse/CASSANDRA-4701 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Reporter: Radim Kolar Assignee: Pavel Yaskevich after some complains about schema synchronization caused by drop,create cf script, i have cassandra in following state. get sipdb[222]; throws an exception but if i use show schema then CF definition is returned correctly. ERROR 16:08:08,377 Exception in thread Thread[ReadStage:33,5,main] java.lang.RuntimeException: java.lang.IllegalArgumentException: Unknown CF 1039 at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(Stora geProxy.java:1257) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.IllegalArgumentException: Unknown CF 1039 at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) at org.apache.cassandra.db.Table.getRow(Table.java:377) at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadComm and.java:69) at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThr ow(StorageProxy.java:819) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(Stora geProxy.java:1253) ... 3 more ERROR 16:28:20,588 Exception in thread Thread[ReadStage:35,5,main] java.lang.RuntimeException: java.lang.IllegalArgumentException: Unknown CF 1039 at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(Stora geProxy.java:1257) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.IllegalArgumentException: Unknown CF 1039 at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) at org.apache.cassandra.db.Table.getRow(Table.java:377) at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadComm and.java:69) at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThr ow(StorageProxy.java:819) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(Stora geProxy.java:1253) ... 3 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4701) get ends with unknown CF exception
[ https://issues.apache.org/jira/browse/CASSANDRA-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463679#comment-13463679 ] Radim Kolar commented on CASSANDRA-4701: its not possible to return error to client instead just of request timeout? get ends with unknown CF exception -- Key: CASSANDRA-4701 URL: https://issues.apache.org/jira/browse/CASSANDRA-4701 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Reporter: Radim Kolar Assignee: Pavel Yaskevich after some complains about schema synchronization caused by drop,create cf script, i have cassandra in following state. get sipdb[222]; throws an exception but if i use show schema then CF definition is returned correctly. ERROR 16:08:08,377 Exception in thread Thread[ReadStage:33,5,main] java.lang.RuntimeException: java.lang.IllegalArgumentException: Unknown CF 1039 at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(Stora geProxy.java:1257) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.IllegalArgumentException: Unknown CF 1039 at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) at org.apache.cassandra.db.Table.getRow(Table.java:377) at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadComm and.java:69) at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThr ow(StorageProxy.java:819) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(Stora geProxy.java:1253) ... 3 more ERROR 16:28:20,588 Exception in thread Thread[ReadStage:35,5,main] java.lang.RuntimeException: java.lang.IllegalArgumentException: Unknown CF 1039 at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(Stora geProxy.java:1257) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.IllegalArgumentException: Unknown CF 1039 at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) at org.apache.cassandra.db.Table.getRow(Table.java:377) at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadComm and.java:69) at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThr ow(StorageProxy.java:819) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(Stora geProxy.java:1253) ... 3 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464320#comment-13464320
]
Radim Kolar commented on CASSANDRA-4687:
Yes its with patch. I am not sure about compaction failing.
My paid work has priority over your demands to edit logfile for you. Its
hundreds MB long and i have just 2GB memory in computer.
If you want that entire logfile then buy it and i will spend half day uploading
it or if you want testsuite from our cassandra fork which can reproduce this
and various other errors, then my ask my company manager, if he is willing to
sell you that testsuite.
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462815#comment-13462815
]
Radim Kolar commented on CASSANDRA-4687:
how to turn on debug output from patch?
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462998#comment-13462998
]
Radim Kolar commented on CASSANDRA-4687:
i dont have log anymore, deleted it. It was too huge ~ 200MB with all debugs on.
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463133#comment-13463133
]
Radim Kolar commented on CASSANDRA-4687:
i am not interested to upload that huge file at my 128kBit unless you pay for
it.
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4707) EOFException during HH delivery
[ https://issues.apache.org/jira/browse/CASSANDRA-4707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461659#comment-13461659 ] Radim Kolar commented on CASSANDRA-4707: Its related to schema changes. Hints were for nonexisting CF, i recreated that CF inserted some data and hints were replayed without error. EOFException during HH delivery --- Key: CASSANDRA-4707 URL: https://issues.apache.org/jira/browse/CASSANDRA-4707 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Environment: windows Reporter: Radim Kolar i have got following error during HH every replay. I did nodetool scrub on system.hintedhandoff and sstable is not corrupted, it must have invalid data inside. INFO [HintedHandoff:10] 2012-09-23 20:26:21,988 HintedHandOffManager.java (line 294) Started hinted handoff for token: 138224439286689469893643387845607487221 with IP: /10.0.0.9 ERROR [HintedHandoff:10] 2012-09-23 20:26:21,988 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[HintedHandoff:10,1,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:259) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:275) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:232) at edu.stanford.ppl.concurrent.SnapTreeMap.init(SnapTreeMap.java:453) at org.apache.cassandra.db.AtomicSortedColumns$Holder.init(AtomicSortedColumns.java:311) at org.apache.cassandra.db.AtomicSortedColumns.init(AtomicSortedColumns.java:77) at org.apache.cassandra.db.AtomicSortedColumns.init(AtomicSortedColumns.java:48) at org.apache.cassandra.db.AtomicSortedColumns$1.fromSorted(AtomicSortedColumns.java:61) at org.apache.cassandra.db.SuperColumnSerializer.deserialize(SuperColumn.java:399) at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:144) at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:136) at org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:129) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:439) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:447) at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:353) at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:256) at org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:84) at org.apache.cassandra.db.HintedHandOffManager$3.runMayThrow(HintedHandOffManager.java:436) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.io.EOFException at java.io.DataInputStream.readFully(DataInputStream.java:197) at java.io.DataInputStream.readFully(DataInputStream.java:169) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:401) at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:380) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:88) at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:255) ... 21 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3741) OOMs because delete operations are not accounted
[ https://issues.apache.org/jira/browse/CASSANDRA-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461662#comment-13461662 ] Radim Kolar commented on CASSANDRA-3741: If you do not want to get fixed, then it should be documented as known bug in NEWS.TXT OOMs because delete operations are not accounted Key: CASSANDRA-3741 URL: https://issues.apache.org/jira/browse/CASSANDRA-3741 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: FreeBSD Reporter: Vitalii Tymchyshyn Assignee: Andriy Kolyadenko Fix For: 1.1.1 Currently we are moving to new data format where new format is written into new CFs and old one is deleted key-by-key. I have started getting OOMs and found out that delete operations are not accounted and so, column families are not flushed (changed == 0 with delete only operations) by storage manager. This is pull request that fixed this problem for me: https://github.com/apache/cassandra/pull/5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
