[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15572584#comment-15572584 ] sankalp kohli commented on CASSANDRA-5988: -- Thanks [~iamaleksey]. > 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)
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15570311#comment-15570311 ] sankalp kohli commented on CASSANDRA-5988: -- Without hintTTL, if we replay data older than GC grace, that will bring back data right? If it is not there in 3.0, it should be fixed as Major if not blocker? > 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)
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[
https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568350#comment-15568350
]
Aleksey Yeschenko commented on CASSANDRA-5988:
--
[~kohlisankalp] Will need to either modify {{HintsDispatcher}} logic to take
'maxhintttl' into account (compared to current time - hint's creationTime), or
do the same even earlier, in {{HintsReader}}. The former is probably cleaner;
the latter can be done a bit more efficiently - skipping hint body entirely if
gcgs/creationTime/maxhinttl combination says the hint is basically dead.
Don't have time atm to do it, but [~bdeggleston] should be pretty familiar with
that code, as he added compression logic - I can review.
> 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)
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567501#comment-15567501 ] sankalp kohli commented on CASSANDRA-5988: -- [~iamaleksey] I could not search "cassandra.maxHintTTL" in 3.0.9. With new hints in 3.0, how can we change this? > 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)
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806920#comment-13806920 ] Brandon Williams commented on CASSANDRA-5988: - I couldn't get this patch to apply, but it was simple enough to just recreate, so I committed it to 1.2. It looks like we need a separate patch for 2.0/trunk, however. Make hint TTL customizable -- Key: CASSANDRA-5988 URL: https://issues.apache.org/jira/browse/CASSANDRA-5988 Project: Cassandra Issue Type: Bug Components: Core Reporter: Oleg Kibirev Labels: patch 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.1#6144)
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806938#comment-13806938 ] Brandon Williams commented on CASSANDRA-5988: - I should note that I also changed the property name to cassandra.maxHintTTL Make hint TTL customizable -- Key: CASSANDRA-5988 URL: https://issues.apache.org/jira/browse/CASSANDRA-5988 Project: Cassandra Issue Type: Bug Components: Core 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.1#6144)
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801114#comment-13801114 ] Vishy Kasar commented on CASSANDRA-5988: Attached the diff as a file 5988.txt Make hint TTL customizable -- Key: CASSANDRA-5988 URL: https://issues.apache.org/jira/browse/CASSANDRA-5988 Project: Cassandra Issue Type: Bug Components: Core Reporter: Oleg Kibirev Labels: patch 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.1#6144)
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765717#comment-13765717 ] Brandon Williams commented on CASSANDRA-5988: - So this would be per-cf? That's how hints are TTL'd currently. Make hint TTL customizable -- Key: CASSANDRA-5988 URL: https://issues.apache.org/jira/browse/CASSANDRA-5988 Project: Cassandra Issue Type: Bug Components: Core Reporter: Oleg Kibirev 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765724#comment-13765724 ] Oleg Kibirev commented on CASSANDRA-5988: - That would be ideal, yes. Make hint TTL customizable -- Key: CASSANDRA-5988 URL: https://issues.apache.org/jira/browse/CASSANDRA-5988 Project: Cassandra Issue Type: Bug Components: Core Reporter: Oleg Kibirev 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765765#comment-13765765 ] Oleg Kibirev commented on CASSANDRA-5988: - Referencing the above JIRA, there is no harm in having smaller hint TTL. As for optimistic locking, the only other form (CAS) is not available until cassandra 2.0 and even then does not provide performance for very high volume operations. If the objective is to do a user facing operation and a background operation simultaneously and without external locking, and to have background operation lose if there is an intervening user operation, backdating the background operation by a certain amount is a good compromise between consistency and performance. This feature will safeguard against user operation failing, being only stored as a hint and then confusing the background process as to ultimate success or failure of the backdated operation. Make hint TTL customizable -- Key: CASSANDRA-5988 URL: https://issues.apache.org/jira/browse/CASSANDRA-5988 Project: Cassandra Issue Type: Bug Components: Core Reporter: Oleg Kibirev 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765737#comment-13765737 ] Jonathan Ellis commented on CASSANDRA-5988: --- Hint TTL will be exactly gc grace for the reasons documented in CASSANDRA-5314. using backdated deletes as a form of optimistic locking sounds like a bad idea, would you care to defend it? :) Make hint TTL customizable -- Key: CASSANDRA-5988 URL: https://issues.apache.org/jira/browse/CASSANDRA-5988 Project: Cassandra Issue Type: Bug Components: Core Reporter: Oleg Kibirev 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
[ https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13762414#comment-13762414 ] sankalp kohli commented on CASSANDRA-5988: -- We also want to make sure that hint TTL is less than gc grace period. Make hint TTL customizable -- Key: CASSANDRA-5988 URL: https://issues.apache.org/jira/browse/CASSANDRA-5988 Project: Cassandra Issue Type: Bug Components: Core Reporter: Oleg Kibirev 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
