cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime
Date Fri, 26 Jan 2018 23:14:00 GMT

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

Paulo Motta edited comment on CASSANDRA-14092 at 1/26/18 11:13 PM:
-------------------------------------------------------------------

This patch below takes a simpler and more transparent approach. The idea is to keep the maximum
allowed TTL of 20 years, but cap the maximum expiration time to 2038-01-19T03:14:06+00:00.

When this capping is done, the following log is print in the client and system.log:
{noformat}
WARN  [SharedPool-Worker-2] 2018-01-26 19:15:36,877 NoSpamLogger.java:94 - TTL of 630720000
seconds exceeds maximum supported expiration date of 2038-01-19T03:14:06+00:00. Rows with
expiration date exceeding the maximum supported date will expire in the limit date. In order
to avoid this use a lower TTL or upgrade to a version where this limitation is fixed. See
CASSANDRA-14092 for more details.
{noformat}
In addition to this, the patch converts any negative localExpirationTime that may have been
written to 2038-01-19T03:14:06+00:00 - fixing any wrong entries that may still be present
but were not yet purged.

Since we store the TTL as a separate field, once we fix this limitation we can recompute the
correct expiration time with the timestamp/1000+ttl time during upgradesstables.

I added tests to check that data inserted with a TTL exceeding the maximum allowed expiration
time is present and a warning is logged. I also added tests to check that SSTables written
with the negative localExpirationTime are correctly interpreted.

||2.1||2.2||3.0||trunk||dtest||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:2.1-14092-v2]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-14092-v2]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-14092-v2]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-14092-v2]|[branch|https://github.com/apache/cassandra-dtest/compare/master...pauloricardomg:14092]|


Submitted CI, will attach results when ready.


was (Author: pauloricardomg):
This patch below takes a simpler and more transparent approach. The idea is to keep the maximum
allowed TTL of 20 years, but cap the maximum expiration time to 2038-01-19T03:14:06+00:00.

When this capping is done, the following log is print in the client and system.log:
{noformat}
WARN  [SharedPool-Worker-2] 2018-01-26 19:15:36,877 NoSpamLogger.java:94 - TTL of 630720000
seconds exceeds maximum supported expiration date of 2038-01-19T03:14:06+00:00. Rows with
expiration date exceeding the maximum supported date will expire in the limit date. In order
to avoid this use a lower TTL or upgrade to a version where this limitation is fixed. See
CASSANDRA-14092 for more details.
{noformat}
In addition to this, the patch converts any negative localExpirationTime that may have been
written to 2038-01-19T03:14:06+00:00 - fixing any wrong entries that may still be present
but were not yet purged.

Since we store the TTL as a separate field, once we fix this limitation we can recompute the
correct expiration time with the timestamp/1000+ttl time during upgradesstables.

I added tests to check that data inserted with a TTL exceeding the maximum allowed expiration
time is present and a warning is logged. I also added tests to check that SSTables written
with the negative localExpirationTime are correctly interpreted.

||2.1||2.2||3.0||trunk||dtest||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:2.1-14092-v2]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-14092-v2]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-14092-v2]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-14092-v2]|[branch|https://github.com/apache/cassandra-dtest/compare/master...pauloricardomg:14092-v2]|


Submitted CI, will attach results when ready.

> 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: Major
>
> 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