[
https://issues.apache.org/jira/browse/CASSANDRA-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345640#comment-16345640
]
Sam Tunnicliffe commented on CASSANDRA-14092:
---------------------------------------------
This is a nasty problem because all the potential solutions are bad and I
should say that I've only gone in depth on the 3.0 patch as of yet, but I
assume that the other versions are functionally equivalent.
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.
However, there is another issue as the current patch can also lead to
previously 'gone' data being resurrected without warning or notification. If an
SSTable contains data with an overflowed expiration, from the client's
perspective that data is not present. Applying the patch before the data is
purged fixes up the expiration date, capping it at the limit date and so the
previously gone data will once again be returned in query results. 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. My preference would be for gone data to stay gone, with
another -D flag to turn on post-insert capping of the expiration date.
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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
