[
https://issues.apache.org/jira/browse/CASSANDRA-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345668#comment-16345668
]
Jeremiah Jordan commented on CASSANDRA-14092:
---------------------------------------------
{quote}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.
{quote}
I think our default should be to cap with warnings. What is a user going to do
when they get the error? They are going to just go change there code to pick a
new date that is still real big, so I don't see a reason to fail things.
{quote}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.
{quote}
We need a way to let users recover the data that was silently dropped. I could
see an argument for a -D to let the data stay dropped, rather than recovering
it, but I definitely think our default here should be to recover the lost data.
{quote}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.
{quote}
Does this actually happen? The expiration date will be fixed up when the cell
is loaded, so on compaction it should be written back out with the new time?
If this is not what happens then it is an over sight in the patch and should be
fixed.
> 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]
