[ 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