cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremiah Jordan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime
Date Tue, 30 Jan 2018 19:42:00 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345668#comment-16345668
] 

Jeremiah Jordan commented on CASSANDRA-14092:
---------------------------------------------

{quote}I have serious concerns about the default action here being to fix up the data. IMO,
the default action should be to reject client requests which attempt to set a TTL that's going
to push expiration/deletion time past the threshold. As mentioned on the dev list there might
be clients out there that can't easily tolerate that, so my suggestion would be that we enable
the capping of the expiration date (at insert/update time only and with a client + log warning)
by means of a -D flag. All of which is definitely annoying and ugly, but probably not too
controversial.
{quote}
I think our default should be to cap with warnings.  What is a user going to do when they
get the error?  They are going to just go change there code to pick a new date that is still
real big, so I don't see a reason to fail things.
{quote}Whether we should allow this resurrection is IMO highly questionable, not knowing what
decisions have been taken outside of the database based on that data not being present/visible.
{quote}
We need a way to let users recover the data that was silently dropped.  I could see an argument
for a -D to let the data stay dropped, rather than recovering it, but I definitely think our
default here should be to recover the lost data.
{quote}Moreover, this resurrection is temporary and persists only until the SSTable is involved
in a compaction. At that point, the expiration date causes a purge and the data disappears
again. This is definitely not cool and if we do fix up the data, it has to stay fixed up.
{quote}
Does this actually happen?  The expiration date will be fixed up when the cell is loaded,
so on compaction it should be written back out with the new time?  If this is not what happens
then it is an over sight in the patch and should be fixed.

> Max ttl of 20 years will overflow localDeletionTime
> ---------------------------------------------------
>
>                 Key: CASSANDRA-14092
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14092
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Paulo Motta
>            Assignee: Paulo Motta
>            Priority: Blocker
>             Fix For: 2.1.20, 2.2.12, 3.0.16, 3.11.2
>
>
> CASSANDRA-4771 added a max value of 20 years for ttl to protect against [year 2038 overflow
bug|https://en.wikipedia.org/wiki/Year_2038_problem] for {{localDeletionTime}}.
> It turns out that next year the {{localDeletionTime}} will start overflowing with the
maximum ttl of 20 years ({{System.currentTimeMillis() + ttl(20 years) > Integer.MAX_VALUE}}),
so we should remove this limitation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message