[
https://issues.apache.org/jira/browse/CASSANDRA-5799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5799:
----------------------------------------
Attachment: 5799.txt
bq. If it requires compaction to take longer than TTL to be a problem
No, it only requires that a TTL expire between the first and second phase,
which can happen whatever the TTL and compaction time is. For some reason,
DeletionTime.isDeleted(), which is just supposed to check if the deletion time
shadows a given column is completely broken (it checks if the columns is
deleted which shouldn't even matter for that method) and depends on the current
time. Attaching simple patch to fix.
> Column can expire while lazy compacting it...
> ---------------------------------------------
>
> Key: CASSANDRA-5799
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5799
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.2.7
> Reporter: Fabien Rousseau
> Assignee: Sylvain Lebresne
> Attachments: 5799.txt
>
>
> Using TTL + range tombstones can lead to failure while lazy compacting rows.
> Scenario to reproduce :
> - create an SSTable with one row and some columns and a TTL of 8 seconds
> - wait one second
> - create a second SSTable with the same rowkey as above, and add a range
> tombstone
> - start the first pass of the lazy compaction before the columns with TTL
> are expired
> - wait 10 seconds (enough for columns with TTL to expire)
> - continue lazy expiration
> - the following assertion will fail :
> [junit] junit.framework.AssertionFailedError: originally calculated
> column size of 1379 but now it is 1082
> [junit] at
> org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:150)
--
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
