You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Wade Simmons (JIRA)" <ji...@apache.org> on 2012/06/05 08:10:23 UTC
[jira] [Created] (CASSANDRA-4307) isMarkedForDelete can return
false if it is a few seconds in the future
Wade Simmons created CASSANDRA-4307:
---------------------------------------
Summary: isMarkedForDelete can return false if it is a few seconds in the future
Key: CASSANDRA-4307
URL: https://issues.apache.org/jira/browse/CASSANDRA-4307
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: Wade Simmons
The patch in CASSANDRA-3716 causes some weird issues to arrise when server times don't exactly match up (and since the resolution is seconds, it is easy to be off by just enough to see it).
I am seeing a case where during schema propagation .isMarkedForDelete() is checked, but the timestamp is a few seconds in the future because the schema was sent from a different node. The code then happily tries to interpret the value of the column as a String, but it is actually the Int encoded deletion time.
Here is an example in the code that does this check and will do the wrong thing if the deletion timestamp is even just a few seconds in the future: https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java#L607-609
To prove that this is a problem, here is a stack trace of a machine trying to interpret the "localDeletionTime" value of a DeletedColumn as UTF-8 because the .isMarkedForDeletion() check failed:
https://gist.github.com/deb064d4377d206368d3
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4307) isMarkedForDelete can return
false if it is a few seconds in the future
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-4307:
----------------------------------------
Attachment: 4307.txt
I believer you're right, good catch!
Attaching patch to re-add the overwrite of isMarkedForDelete in DeletedColumn. We shouldn't have removed it since DeletedColumn should never ever be interpreted as live columns, even with lack of node synchronization (it's ok for expiring columns though).
> isMarkedForDelete can return false if it is a few seconds in the future
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-4307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4307
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Wade Simmons
> Fix For: 1.1.2
>
> Attachments: 4307.txt
>
>
> The patch in CASSANDRA-3716 causes some weird issues to arrise when server times don't exactly match up (and since the resolution is seconds, it is easy to be off by just enough to see it).
> I am seeing a case where during schema propagation .isMarkedForDelete() is checked, but the timestamp is a few seconds in the future because the schema was sent from a different node. The code then happily tries to interpret the value of the column as a String, but it is actually the Int encoded deletion time.
> Here is an example in the code that does this check and will do the wrong thing if the deletion timestamp is even just a few seconds in the future: https://github.com/apache/cassandra/blob/47f0cc5d38d272ec9f7d6179eb3ffa28c6f74107/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java#L607-609
> To prove that this is a problem, here is a stack trace of a machine trying to interpret the "localDeletionTime" value of a DeletedColumn as UTF-8 because the .isMarkedForDeletion() check failed:
> https://gist.github.com/deb064d4377d206368d3
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4307) isMarkedForDelete can return
false if it is a few seconds in the future
Posted by "Wade Simmons (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Wade Simmons updated CASSANDRA-4307:
------------------------------------
Attachment: 4307-test.txt
Test case to ensure no future regressions. Fails if 4307 patch is not applied.
> isMarkedForDelete can return false if it is a few seconds in the future
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-4307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4307
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Wade Simmons
> Assignee: Sylvain Lebresne
> Fix For: 1.1.2
>
> Attachments: 4307-test.txt, 4307.txt
>
>
> The patch in CASSANDRA-3716 causes some weird issues to arrise when server times don't exactly match up (and since the resolution is seconds, it is easy to be off by just enough to see it).
> I am seeing a case where during schema propagation .isMarkedForDelete() is checked, but the timestamp is a few seconds in the future because the schema was sent from a different node. The code then happily tries to interpret the value of the column as a String, but it is actually the Int encoded deletion time.
> Here is an example in the code that does this check and will do the wrong thing if the deletion timestamp is even just a few seconds in the future: https://github.com/apache/cassandra/blob/47f0cc5d38d272ec9f7d6179eb3ffa28c6f74107/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java#L607-609
> To prove that this is a problem, here is a stack trace of a machine trying to interpret the "localDeletionTime" value of a DeletedColumn as UTF-8 because the .isMarkedForDeletion() check failed:
> https://gist.github.com/deb064d4377d206368d3
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4307) isMarkedForDelete can return
false if it is a few seconds in the future
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289494#comment-13289494 ]
Jonathan Ellis commented on CASSANDRA-4307:
-------------------------------------------
+1
> isMarkedForDelete can return false if it is a few seconds in the future
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-4307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4307
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Wade Simmons
> Assignee: Sylvain Lebresne
> Fix For: 1.1.2
>
> Attachments: 4307.txt
>
>
> The patch in CASSANDRA-3716 causes some weird issues to arrise when server times don't exactly match up (and since the resolution is seconds, it is easy to be off by just enough to see it).
> I am seeing a case where during schema propagation .isMarkedForDelete() is checked, but the timestamp is a few seconds in the future because the schema was sent from a different node. The code then happily tries to interpret the value of the column as a String, but it is actually the Int encoded deletion time.
> Here is an example in the code that does this check and will do the wrong thing if the deletion timestamp is even just a few seconds in the future: https://github.com/apache/cassandra/blob/47f0cc5d38d272ec9f7d6179eb3ffa28c6f74107/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java#L607-609
> To prove that this is a problem, here is a stack trace of a machine trying to interpret the "localDeletionTime" value of a DeletedColumn as UTF-8 because the .isMarkedForDeletion() check failed:
> https://gist.github.com/deb064d4377d206368d3
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4307) isMarkedForDelete can return
false if it is a few seconds in the future
Posted by "Wade Simmons (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Wade Simmons updated CASSANDRA-4307:
------------------------------------
Description:
The patch in CASSANDRA-3716 causes some weird issues to arrise when server times don't exactly match up (and since the resolution is seconds, it is easy to be off by just enough to see it).
I am seeing a case where during schema propagation .isMarkedForDelete() is checked, but the timestamp is a few seconds in the future because the schema was sent from a different node. The code then happily tries to interpret the value of the column as a String, but it is actually the Int encoded deletion time.
Here is an example in the code that does this check and will do the wrong thing if the deletion timestamp is even just a few seconds in the future: https://github.com/apache/cassandra/blob/47f0cc5d38d272ec9f7d6179eb3ffa28c6f74107/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java#L607-609
To prove that this is a problem, here is a stack trace of a machine trying to interpret the "localDeletionTime" value of a DeletedColumn as UTF-8 because the .isMarkedForDeletion() check failed:
https://gist.github.com/deb064d4377d206368d3
was:
The patch in CASSANDRA-3716 causes some weird issues to arrise when server times don't exactly match up (and since the resolution is seconds, it is easy to be off by just enough to see it).
I am seeing a case where during schema propagation .isMarkedForDelete() is checked, but the timestamp is a few seconds in the future because the schema was sent from a different node. The code then happily tries to interpret the value of the column as a String, but it is actually the Int encoded deletion time.
Here is an example in the code that does this check and will do the wrong thing if the deletion timestamp is even just a few seconds in the future: https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java#L607-609
To prove that this is a problem, here is a stack trace of a machine trying to interpret the "localDeletionTime" value of a DeletedColumn as UTF-8 because the .isMarkedForDeletion() check failed:
https://gist.github.com/deb064d4377d206368d3
> isMarkedForDelete can return false if it is a few seconds in the future
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-4307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4307
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Wade Simmons
>
> The patch in CASSANDRA-3716 causes some weird issues to arrise when server times don't exactly match up (and since the resolution is seconds, it is easy to be off by just enough to see it).
> I am seeing a case where during schema propagation .isMarkedForDelete() is checked, but the timestamp is a few seconds in the future because the schema was sent from a different node. The code then happily tries to interpret the value of the column as a String, but it is actually the Int encoded deletion time.
> Here is an example in the code that does this check and will do the wrong thing if the deletion timestamp is even just a few seconds in the future: https://github.com/apache/cassandra/blob/47f0cc5d38d272ec9f7d6179eb3ffa28c6f74107/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java#L607-609
> To prove that this is a problem, here is a stack trace of a machine trying to interpret the "localDeletionTime" value of a DeletedColumn as UTF-8 because the .isMarkedForDeletion() check failed:
> https://gist.github.com/deb064d4377d206368d3
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira