[ 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:10 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. ||cassandra-2.1||cassandra-2.2||cassandra-3.0||trunk||dtest|| |[branch|https://github.com/apache/cassandra/compare/cassandra-cassandra-2.1...pauloricardomg:cassandra-2.1-14092-v2]|[branch|https://github.com/apache/cassandra/compare/cassandra-cassandra-2.2...pauloricardomg:cassandra-2.2-14092-v2]|[branch|https://github.com/apache/cassandra/compare/cassandra-cassandra-3.0...pauloricardomg:cassandra-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. ||cassandra-2.1||cassandra-2.2||cassandra-3.0||trunk||dtest|| |[branch|https://github.com/apache/cassandra/compare/cassandra-cassandra-2.1...pauloricardomg:cassandra-2.1-14092]|[branch|https://github.com/apache/cassandra/compare/cassandra-cassandra-2.2...pauloricardomg:cassandra-2.2-14092]|[branch|https://github.com/apache/cassandra/compare/cassandra-cassandra-3.0...pauloricardomg:cassandra-3.0-14092]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-14092]|[branch|https://github.com/apache/cassandra-dtest/compare/master...pauloricardomg:14092]| 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org