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

Paulo Motta commented on CASSANDRA-14092:
-----------------------------------------

bq. 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.

My reasoning for this is that once we fix the issue permanently, the idea is to 
restore/recompute the correct localDeletionTime via (timestamp/1000 + ttl). 
This is obviously not perfect as the timestamp could be provided by the client, 
so there could be some slight variance here, but if someone is setting a TTL 20 
years in advance, I think it is able to tolerate a few seconds or even minutes 
of difference in the expiration time. I don't think the case where the client 
is using a different timestamp format plus overflowing TTL is realistic enough 
that it will create problems, but we can also protect against this and perhaps 
provide and option to opt out of fix by default behavior if necessary.

> 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

Reply via email to