[
https://issues.apache.org/jira/browse/CASSANDRA-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345706#comment-16345706
]
Paulo Motta edited comment on CASSANDRA-14092 at 1/30/18 8:02 PM:
------------------------------------------------------------------
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 localExpirationTime 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.
was (Author: pauloricardomg):
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
