[
https://issues.apache.org/jira/browse/CASSANDRA-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16349529#comment-16349529
]
Kurt Greaves commented on CASSANDRA-14092:
------------------------------------------
To clarify, CAP and CAP_NOWARN will cap the expiry but we'll have NO INTENTION
of ever fixing it in an upgrade? Or would they have to do a scrub to convert
anything that got capped to its actual TTL?
I think it's worth pointing out that REJECT is a ticking time bomb. The main
concern being people who are still running anything <4.0 when their TTL's
breach 2038-01-19 (which could be literally at any time). If the default was
CAP and warn, fixing after upgrade then at least we wouldn't be bound to break
peoples application in the future, and we'd still have almost 20 years to get
everyone off these versions without breaking their applications.
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
