You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2011/03/12 12:19:59 UTC
[jira] Created: (CASSANDRA-2317) Column family deletion time is not
always reseted after gc_grace
Column family deletion time is not always reseted after gc_grace
----------------------------------------------------------------
Key: CASSANDRA-2317
URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.6
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Follow up of CASSANDRA-2305.
Reproducible (thanks to Jeffrey Wang) by:
Create a CF with gc_grace_seconds = 0 and no row cache.
Insert row X, col A with timestamp 0.
Insert row X, col B with timestamp 2.
Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
Wait 1 second.
Force flush and compaction.
Insert row X, col A with timestamp 0.
Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2317) Column family deletion time is not
always reseted after gc_grace
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-2317:
----------------------------------------
Attachment: 0002-Reset-cf-deletion-time-after-gc-grace.patch
0001-Add-unit-test.patch
Adding patch against 0.7.
First patch is a unit test to reproduce the failure, patch 2 is the fix.
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Attachments: 0001-Add-unit-test.patch, 0002-Reset-cf-deletion-time-after-gc-grace.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2317) Column family deletion time is
not always reseted after gc_grace
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006449#comment-13006449 ]
Sylvain Lebresne commented on CASSANDRA-2317:
---------------------------------------------
This is clearly not of big importance.
I however think that we should fix this for coherence sake. Tombstones have side effects on client queries and tombstone collection too (it's not just an internal detail). As such, we should make the behavior as coherent as possible. That a deletion always has effect until the first compaction after gc_grace would be more coherent that the current status quo. The fact that Jeffrey was surprised and that we assume right away that it was a bug proves that, I think.
And the fix is actually fairly simple, even though my patch doesn't do it justice. The first patch is really just a refactoring that I think should have been done a long time ago. I'm happy to create a ticket for this specifically if we prefer, but I just think it is stupid to not factor that code.
The second part of the patch is to put markedDeletedAt and localDeletionTime in a common structure that we CAS for changes. Again, this is because right now I think we have a race condition when updating those two values. That is, we could end up with the markedDeleteAt of a given operation but the localDeletionTime of another one. This could also be put on another ticket (I just tend to be lazy so I've put everything here, sorry).
Once those are done, the fix for this specific ticket is really just the maybeResetDeletionTime() function.
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.7.5
>
> Attachments: 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, 0002-Add-unit-test.patch, 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2317) Column family deletion time is not
always reseted after gc_grace
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-2317:
----------------------------------------
Attachment: (was: 0002-Reset-cf-deletion-time-after-gc-grace.patch)
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Attachments: 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, 0002-Add-unit-test.patch, 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2317) Column family deletion time is
not always reseted after gc_grace
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006426#comment-13006426 ]
Jonathan Ellis commented on CASSANDRA-2317:
-------------------------------------------
Oh, so the problem is that we're not actually losing information (when a CF contains non-deleted data) that we may lose otherwise?
Is that really worth adding a bunch of complexity to "fix?"
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.7.5
>
> Attachments: 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, 0002-Add-unit-test.patch, 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2317) Column family deletion time is not
always reseted after gc_grace
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-2317:
----------------------------------------
Attachment: (was: 0001-Add-unit-test.patch)
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Attachments: 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, 0002-Add-unit-test.patch, 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2317) Column family deletion time is
not always reseted after gc_grace
Posted by "Jeffrey Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053510#comment-13053510 ]
Jeffrey Wang commented on CASSANDRA-2317:
-----------------------------------------
Does anyone know whether this is fixed in 0.8? We are thinking of upgrading soon, but I don't want to try to apply the 0.7 patch to 0.8...
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.7.7
>
> Attachments: 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, 0002-Add-unit-test.patch, 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2317) Column family deletion time is
not always reseted after gc_grace
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053534#comment-13053534 ]
Jonathan Ellis commented on CASSANDRA-2317:
-------------------------------------------
"Unresolved" means not fixed anywhere yet.
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.7.7
>
> Attachments: 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, 0002-Add-unit-test.patch, 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2317) Column family deletion time is
not always reseted after gc_grace
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059460#comment-13059460 ]
Sylvain Lebresne commented on CASSANDRA-2317:
---------------------------------------------
Committed to trunk (as I agree this should really go there).
bq. doesn't this mean that for a CF w/ no tombstone, we create a new deletioninfo every call to maybeReset?
You're right, I've included a current.localDeletionTime == Integer.MIN_VALUE in the condition to escape early in that case.
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.0
>
> Attachments: 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, 0002-Add-unit-test.patch, 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2317) Column family deletion time is
not always reseted after gc_grace
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059477#comment-13059477 ]
Hudson commented on CASSANDRA-2317:
-----------------------------------
Integrated in Cassandra #948 (See [https://builds.apache.org/job/Cassandra/948/])
Reset CF and SC deletion time after gc_grace
patch by slebresne; reviewed by jbellis for CASSANDRA-2317
slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1142690
Files :
* /cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamily.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/filter/QueryFilter.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/RowMutation.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/SuperColumn.java
* /cassandra/trunk/CHANGES.txt
* /cassandra/trunk/test/unit/org/apache/cassandra/service/RowResolverTest.java
* /cassandra/trunk/test/unit/org/apache/cassandra/db/RowTest.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/IColumnContainer.java
* /cassandra/trunk/test/unit/org/apache/cassandra/db/compaction/CompactionsPurgeTest.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/AbstractColumnContainer.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilySerializer.java
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.0
>
> Attachments: 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, 0002-Add-unit-test.patch, 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2317) Column family deletion time is not
always reseted after gc_grace
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-2317:
----------------------------------------
Attachment: 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
0002-Add-unit-test.patch
0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch
bq. How do you have CF objects around at all post-purge?
The problem is actually with cf objects that don't get fully purged. Those still retain their markedForDeleteAt and localDeletionTime after compaction even though it could be way past gc_grace. That is, a deletion can easily live way past gc_grace + compaction.
As it turns out, super columns also suffers for the same problem.
Because it felt a bit annoying to have to fix the problem in 2 places, and because that's not the first time that happens, the first attached is a refactoring one, that introduces an AbstractColumnContainer class that factor common code to ColumnFamily and SuperColumn.
The second patch introduces unit tests for column family and super columns and third patch is the fix. It introduces a new structure to hold both markedDeletedAt and localDeletionTime so that we are able to set both of those together atomically. This is necessary for the second part of CASSANDRA-2305. I think that anyhow it was not fully correct to update them non atomically.
Note that the third patch depends on the patch for CASSANDRA-2279.
All patches are against 0.7.
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Attachments: 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, 0002-Add-unit-test.patch, 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2317) Column family deletion time is
not always reseted after gc_grace
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048725#comment-13048725 ]
Jonathan Ellis commented on CASSANDRA-2317:
-------------------------------------------
doesn't this mean that for a CF w/ no tombstone, we create a new deletioninfo every call to maybeReset?
bq. if (current.localDeletionTime > gcBefore || deletionInfo.compareAndSet(current, new DeletionInfo()))
otherwise, +1 for trunk.
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.7.7
>
> Attachments: 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, 0002-Add-unit-test.patch, 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2317) Column family deletion time is
not always reseted after gc_grace
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006038#comment-13006038 ]
Sylvain Lebresne commented on CASSANDRA-2317:
---------------------------------------------
I realize this fix don't take the cache into account. I'll attach an updated patch asap.
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Attachments: 0001-Add-unit-test.patch, 0002-Reset-cf-deletion-time-after-gc-grace.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2317) Column family deletion time is
not always reseted after gc_grace
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006044#comment-13006044 ]
Jonathan Ellis commented on CASSANDRA-2317:
-------------------------------------------
How do you have CF objects around at all post-purge?
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Attachments: 0001-Add-unit-test.patch, 0002-Reset-cf-deletion-time-after-gc-grace.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira