cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime
Date Fri, 09 Feb 2018 12:16:00 GMT

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

Sam Tunnicliffe edited comment on CASSANDRA-14092 at 2/9/18 12:15 PM:
----------------------------------------------------------------------

{quote}Since 4.0 was not released, and it will come out with this fix it's impossible that
someone will hit this on 4.0, but I don't see any problem in keeping the scrub option for
the lazy ones upgrading from 3.x without fixing their SSTables beforehand.
{quote}
yeah, this was the scenario I was thinking about.
{quote}I now wonder if this notice has gotten to big and is cluttering the NEWS.txt file too
much - what may confuse users looking for upgrade instructions - and we should maybe create
a new WARNING/IMPORTANT file and add a pointer to it in the NEWS.txt file instead?
{quote}
I tend to agree with you. Even if adding another file is less than ideal, it's probably better
than adding a large, unchanging header as that's likely just going to lead to more users not
properly reading it and missing critical info about other future upgrades. So I'd be +1 on
adding a new file ({{CASSANDRA\-14092.txt}} maybe?) and just a brief explanation of the severity
of the issue plus a *very* clear pointer to more detailed file at the top of {{NEWS.txt}}.
I think you should keep the
{code:java}
WARNING: MAXIMUM TTL EXPIRATION DATE NOTICE
--------------------------------------------
(General upgrading instructions are available in the next section)

The maximum expiration timestamp that can be represented by the storage engine is 2038-01-19T03:14:06+00:00,
which means that inserts with TTL that expire after this date are not currently supported.
{code}

and add the pointer after that.

1 nit on the text in {{NEWS.txt}}, you have a double "the" in the sentence 
 {{"As time progresses, the maximum supported TTL will be gradually reduced as the the maximum
expiration date approaches."}}

Extracting the news text to a new file notwithstanding, I'm +1 on the latest patches (pending
CI, of course). Thanks for all the hard work on this [~pauloricardomg]


was (Author: beobal):
{quote}Since 4.0 was not released, and it will come out with this fix it's impossible that
someone will hit this on 4.0, but I don't see any problem in keeping the scrub option for
the lazy ones upgrading from 3.x without fixing their SSTables beforehand.
{quote}
yeah, this was the scenario I was thinking about.
{quote}I now wonder if this notice has gotten to big and is cluttering the NEWS.txt file too
much - what may confuse users looking for upgrade instructions - and we should maybe create
a new WARNING/IMPORTANT file and add a pointer to it in the NEWS.txt file instead?
{quote}
I tend to agree with you. Even if adding another file is less than ideal, it's probably better
than adding a large, unchanging header as that's likely just going to lead to more users not
properly reading it and missing critical info about other future upgrades. So I'd be +1 on
adding a new file ({{CASSANDRA\-14092.txt}} maybe?) and just a brief explanation of the severity
of the issue plus a *very* clear pointer to more detailed file at the top of {{NEWS.txt}}.
I think you should keep the
{code:java}
WARNING: MAXIMUM TTL EXPIRATION DATE NOTICE
--------------------------------------------
(General upgrading instructions are available in the next section)

The maximum expiration timestamp that can be represented by the storage engine is 2038-01-19T03:14:06+00:00,
which means that inserts with TTL that expire after this date are not currently supported.
{code}

and add the pointer after that.

1 nit on the text in {{NEWS.txt}}, you have a double "the" in the sentence 
 {{"As time progresses, the maximum supported TTL will be gradually reduced as the the maximum
expiration date approaches."}}

Extracting the news text to a new file notwithstanding, I'm +1 on the latest patches. Thanks
for all the hard work on this [~pauloricardomg]

> 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message