[ 
https://issues.apache.org/jira/browse/CASSANDRA-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Binh Van Nguyen updated CASSANDRA-5182:
---------------------------------------

    Attachment: test_ttl.tar.gz

Here is simple code to reproduce the issue. The simple code use 10 threads to 
continuously write to C*. All the column has 300 in its TTL. While running the 
code, check the number of sstable of column family, you will see that it keeps 
growing and never stop
Here are steps to run:
- Start C* on your localhost
- Create a keyspace named test
- Use the following command to create column family cf
CREATE COLUMN FAMILY cf WITH comparator = UTF8Type AND key_validation_class = 
UTF8Type AND default_validation_class = UTF8Type AND gc_grace = 0 AND caching = 
none AND bloom_filter_fp_chance = 1.0 AND 
compaction_strategy='LeveledCompactionStrategy' AND compaction_strategy_options 
= { sstable_size_in_mb : 1 } AND compression_options = { chunk_length_kb : 64, 
sstable_compression : 'SnappyCompressor' };

- Extract the code switch to extracted directory
- Run mvn package
- Run java -jar target/test_ttl-1.0-SNAPSHOT-jar-with-dependencies.jar 10

                
> Deletable rows are sometimes not removed during compaction
> ----------------------------------------------------------
>
>                 Key: CASSANDRA-5182
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5182
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.5
>            Reporter: Binh Van Nguyen
>         Attachments: test_ttl.tar.gz
>
>
> Our use case is write heavy and read seldom.  To optimize the space used, 
> we've set the bloom_filter_fp_ratio=1.0  That along with the fact that each 
> row is only written to one time and that there are more than 20 SSTables 
> keeps the rows from ever being compacted. Here is the code:
> https://github.com/apache/cassandra/blob/cassandra-1.1/src/java/org/apache/cassandra/db/compaction/CompactionController.java#L162
> We hit this conner case and because of this C* keeps consuming more and more 
> space on disk while it should not.

--
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

Reply via email to