[
https://issues.apache.org/jira/browse/CASSANDRA-4771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16337805#comment-16337805
]
Randy Fradin commented on CASSANDRA-4771:
-----------------------------------------
[~christianmovi]: I forgot about this! I just tried on a 2.1 cluster and have
also confirmed it is broken. I get an AssertionError back when doing an insert
with ttl 630720000 (20 years). Are you on Cassandra 3+? I was hoping this was
fixed as part of CASSANDRA-8099, but from that snippet I guess not.
It looks like expiration time is encoded per cell as an offset in seconds from
the minimum deletion time in the SSTable. If I'm reading it right the offset is
serialized as a variable length integer, so reading it into a long would give a
very large range of offsets that would be more than sufficient. However it
looks to me like the minimum deletion time at the SSTable metadata level is
saved as a fixed-size 4-byte signed integer. Without changing the serialization
format we could change the interpretation of that metadata field to assume it
is an unsigned integer (and de-serialize it also into a long variable) which
should indeed give us another 68 years. A better fix would probably be to also
change the serialization format of the minLocalDeletionTime to an 8 byte
integer or a variable size integer so it could hold values in the far far
future. Changing the SSTable format might be a 4.0+ thing though. This probably
needs a new ticket.
I would gladly accept that beer! But I probably deserve negative points for not
following up on my comment several years ago...
> Setting TTL to Integer.MAX causes columns to not be persisted.
> --------------------------------------------------------------
>
> Key: CASSANDRA-4771
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4771
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.0.12
> Reporter: Todd Nine
> Assignee: Dave Brosius
> Priority: Major
> Fix For: 1.1.6
>
> Attachments: 4771.txt, 4771_b.txt
>
>
> When inserting columns via batch mutation, we have an edge case where columns
> will be set to Integer.MAX. When setting the column expiration time to
> Integer.MAX, the columns do not appear to be persisted.
> Fails:
> Integer.MAX_VALUE
> Integer.MAX_VALUE/2
> Works:
> Integer.MAX_VALUE/3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
