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

Aleksey Yeschenko commented on CASSANDRA-5988:
----------------------------------------------

Nope, we are all good. We store creationTime and gcgs (at the time of hint's 
write), and check against current time (and current gcgs) before replaying. 
Essentially following the old behaviour, except even stricter (we use the min 
of gcgs at the time of writing the hint and the gcgs at the time of replay).

What changed is that you cannot *override* the *max* hintttl in 3.0 anymore to 
make it lower - or larger - than the calculated value.

> Make hint TTL customizable
> --------------------------
>
>                 Key: CASSANDRA-5988
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5988
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Oleg Kibirev
>            Assignee: Vishy Kasar
>              Labels: patch
>             Fix For: 1.2.12, 2.0.3
>
>         Attachments: 5988.txt
>
>
> Currently time to live for stored hints is hardcoded to be gc_grace_seconds. 
> This causes problems for applications using backdated deletes as a form of 
> optimistic locking. Hints for updates made to the same data on which delete 
> was attempted can persist for days, making it impossible to determine if 
> delete succeeded by doing read(ALL) after a reasonable delay. We need a way 
> to explicitly configure hint TTL, either through schema parameter or through 
> a yaml file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to