cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Anastasyev (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-6025) Deleted row resurrects if was not compacted in GC Grace Timeout due to thombstone read optimization in CollactionController
Date Fri, 13 Sep 2013 13:40:52 GMT

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

Oleg Anastasyev updated CASSANDRA-6025:
---------------------------------------

    Description: 
How to reproduce:
1. Insert column
2. Flush, so you'll have sstable-1
3. Delete just inserted column
4. Flush, now you have sstable-2 as well
5. Left it uncompacted for more then gc grace time or just use 0, so you dont have to wait
6. Read data form column. You'll read just deleted column


{code}
            /* add the SSTables on disk */
// This sorts sstables in the order sstable-2, sstable-1
            Collections.sort(view.sstables, SSTable.maxTimestampComparator);
//...
            for (SSTableReader sstable : view.sstables)
            {
//...
                if (iter.getColumnFamily() != null)
//...
                    while (iter.hasNext())
                    {
                        OnDiskAtom atom = iter.next();
// the problem is here. reading atom after gc grace time
// makes this condition false. so tombstone from sstable-2
// is not placed to temp container and is just thrown away.
// On next iteration of outer for statement an original
// data inserted in step 1 from sstable-1 will be read and
// placed to temp.
                        if (atom.getLocalDeletionTime() >= gcBefore)
                            temp.addAtom(atom);
//
                    }

// .. so at the end of the for statemet we resolve data from temp. which
// do not have tombstone at all -> data are resurrected.
{code}


  was:
How to reproduce:
1. Insert column
2. Flush, so you'll have sstable-1
3. Delete just inserted column
4. Flush, now you have sstable-2 as well
5. Left it uncompacted for more then gc grace time or just use 0, so you dont have to wait
6. Read data form column. You'll read just deleted column


{code}
            /* add the SSTables on disk */
// This sorts sstables in the order sstable-2, sstable-1
            Collections.sort(view.sstables, SSTable.maxTimestampComparator);
//...
            for (SSTableReader sstable : view.sstables)
            {
//...
                if (iter.getColumnFamily() != null)
//...
                    while (iter.hasNext())
                    {
                        OnDiskAtom atom = iter.next();
// the problem is here. reading atom after gc grace time
// makes this condition false. so tombstone from sstable-2
// is not placed to temp container and is just thrown away.
// On next iteration of outer for statement an original
// data inserted in step 1 from sstable-1 will be read and
// placed to temp.
                        if (atom.getLocalDeletionTime() >= gcBefore)
                            temp.addAtom(atom);
//
                    }

// .. so at the end of the for statemet we resolve data from temp. which
// do not have tombstone at all -> data are resurrected.


    
> Deleted row resurrects if was not compacted in GC Grace Timeout due to thombstone read
optimization in CollactionController
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6025
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6025
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Oleg Anastasyev
>
> How to reproduce:
> 1. Insert column
> 2. Flush, so you'll have sstable-1
> 3. Delete just inserted column
> 4. Flush, now you have sstable-2 as well
> 5. Left it uncompacted for more then gc grace time or just use 0, so you dont have to
wait
> 6. Read data form column. You'll read just deleted column
> {code}
>             /* add the SSTables on disk */
> // This sorts sstables in the order sstable-2, sstable-1
>             Collections.sort(view.sstables, SSTable.maxTimestampComparator);
> //...
>             for (SSTableReader sstable : view.sstables)
>             {
> //...
>                 if (iter.getColumnFamily() != null)
> //...
>                     while (iter.hasNext())
>                     {
>                         OnDiskAtom atom = iter.next();
> // the problem is here. reading atom after gc grace time
> // makes this condition false. so tombstone from sstable-2
> // is not placed to temp container and is just thrown away.
> // On next iteration of outer for statement an original
> // data inserted in step 1 from sstable-1 will be read and
> // placed to temp.
>                         if (atom.getLocalDeletionTime() >= gcBefore)
>                             temp.addAtom(atom);
> //
>                     }
> // .. so at the end of the for statemet we resolve data from temp. which
> // do not have tombstone at all -> data are resurrected.
> {code}

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

Mime
View raw message