[
https://issues.apache.org/jira/browse/CASSANDRA-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344514#comment-16344514
]
Paulo Motta edited comment on CASSANDRA-14092 at 1/30/18 5:13 AM:
------------------------------------------------------------------
{quote}Some review comments on the dtest and trunk changes:
{quote}
Thanks for your feedback! I addressed your suggestions/nits and updated the
warning message to:
{noformat}
Request on table ks.ttl_table with default ttl of 630720000 seconds exceeds
maximum supported expiration date of 2038-01-19T03:14:06+00:00 and will have
its expiration capped to that 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 the fixes above, [~jasonstack] pointed out offline that the
{{default_time_to_live}} is not capped to 20 years on the 2.1 branch, so I
added the cap
[here|https://github.com/apache/cassandra/commit/4d592eb990c1f7a84ae79738ea3ffb22f67282d3].
This made me realize that the warning was not being print when the insert was
using the table default TTL, so I fixed this
[here|https://github.com/apache/cassandra/commit/109fa214fbedc3b803e47f8dc79b41132ef2a1eb]
and added a dtest
[here|https://github.com/apache/cassandra-dtest/commit/09f39d5910d4c0dd1b800698deec7f7a6c5c747a].
I also added some dtests to check that the warning is print when the access is
done via thrift
([here|https://github.com/apache/cassandra-dtest/commit/748ab67a1ce3950640747d6b980ef57b7871e59b]).
I updated all branches above with the changes above + other minor fixes and
test fixes. Will update with test results when CI is ready.
{quote}I thought I would post a proof of concept branch I had that promotes
localDeletionTime to long on trunk.
{quote}
Thanks a lot for your effort! While this looks like a straightforward approach
and I don't see any particular problems with it at first glance, I'd like to
focus right now on shipping a temporary solution to fix the silent data loss
problem on 3.0+ as soon as we can before working on a permanent solution with
proper vetting, testing and impact analysis.
was (Author: pauloricardomg):
{quote}Some review comments on the dtest and trunk changes:
{quote}
Thanks for your feedback! I addressed your suggestions/nits and updated the
warning message to:
{noformat}
Request on table ks.ttl_table with default ttl of 630720000 seconds exceeds
maximum supported expiration date of 2038-01-19T03:14:06+00:00 and will have
its expiration capped to that 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 the fixes above, [~jasonstack] pointed out offline that the
{{default_time_to_live}} is not capped to 20 years on the 2.1 branch, so I
added the cap
[here|https://github.com/apache/cassandra/commit/4d592eb990c1f7a84ae79738ea3ffb22f67282d3].
This made me realize that the warning was not being print when the insert was
using the table default TTL, so I fixed this
[here|https://github.com/apache/cassandra/commit/109fa214fbedc3b803e47f8dc79b41132ef2a1eb]
and added a dtest
[here|https://github.com/apache/cassandra-dtest/commit/09f39d5910d4c0dd1b800698deec7f7a6c5c747a].
I also added some dtests to check that the warning is print when the access is
done via thrift
([here|https://github.com/apache/cassandra-dtest/commit/748ab67a1ce3950640747d6b980ef57b7871e59b]).
I updated all branches above with the changes above + other minor fixes and
test fixes. Will update with when CI is ready.
{quote}I thought I would post a proof of concept branch I had that promotes
localDeletionTime to long on trunk.
{quote}
Thanks a lot for your effort! While this looks like a straightforward approach
and I don't see any particular problems with it at first glance, I'd like to
focus right now on shipping a temporary solution to fix the silent data loss
problem on 3.0+ as soon as we can before working on a permanent solution with
proper vetting, testing and impact analysis.
> 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]
