Joseph Lynch commented on CASSANDRA-14761:

{quote}We did a speculative name before and it wasn't popular. I think we need 
to settle on something and document it. This is the third time we are changing 
it. Everyone has their own idea of what is best and none are perfect.
Hm, I'm not sure the best way to come to consensus here. We can ask the 
users-list or the cassandra irc channel but I worry about bikeshedding (which I 
may be guilty of here ;) ). My concern is solely that this is a user interface 
that we will want to maintain backwards compatibility for the future so we want 
to get it right (like Benedict mentions) and in my opinion try to align with 
common industry terms at the same time. A quick overview of what various other 
systems in industry call this behavior that I could find:
 * Cassandra 
 Driver: "Speculative Execution Policy" -> {{speculative_execution_policy}}
 * Jeff Dean's [Tail at 
 "Hedged requests" -> {{hedged_request_policy}}
 * [Google SRE 
 (which just cites Tail at Scale): "hedged requests" -> 
 "Hedging policy" -> {{hedging_policy}} or {{hedged_request_policy}}
 "speculative"/"speculative retry"/"speculative execution" (depending on the 
version): -> {{speculative_retry}} or {{speculative_execution_policy}}
 * [Spark|https://spark.apache.org/docs/latest/configuration.html] : boolean 
"speculation" -> {{speculative_execution_policy}}
 * [CPU chip design|https://en.wikipedia.org/wiki/Speculative_execution] (maybe 
not a fair analogy, shrug): "speculative execution" -> 

I've also anecdotally heard "eager reads/retry", "rapid read protection", and a 
few others. I can't find anywhere in the literature that "additional requests" 
or "additional reads" are used. Just considering the literature review I 
believe the best UIs would either involve "speculation" or "hedging". Some 
||Root||Read Requests||Transient Replica Upgrade / Write Requests||
|"speculation" option 
|"speculation" option 2 (similar to status 
|"speculation" option 
|"speculation" option 
|"hedged" option 1|{{hedged_read_policy}}|{{hedged_transient_upgrade_policy}}|
|"hedged" option 2|{{read_hedging_policy}}|{{transient_write_hedging_policy}}|
|current proposal|{{additional_read_policy}}|{{additional_write_policy}}|

If I understand the feature correctly we could also make the UI potentially 
more consistent by having non transient keyspaces just have the write 
speculation option as "ALWAYS" even if the code doesn't look at it and it can't 
be changed (if I understand the feature properly, non transient replicas don't 
need this because we send writes to all full data replicas anyways). I 
personally like speculation option 3 since it matches the drivers and doesn't 
conflate speculative execution and transient write replica upgrades...
 Overall the code looks good to me assuming the unit/dtests pass on rebase, 
just a few comments/questions (and obviously we have to figure out what we're 
going to call this ...)
 * Needs a rebase and re-test run, sorry about the review lag
 * Can we use {{createTableCounter(String name, String alias)}} 
 instead of adding the {{reregisterTableCounter}} 
 If not can we document in a comment why these aliases are special in a comment?
 * I guess we need CASSANDRA-14975 before we know if the cqlsh tests are 
working ... my local runs look somewhat red but it appears to mostly be because 
of {{No keyspace has been specified. USE a keyspace}}. I played around manually 
with cqlsh and things appear to work reasonably all right.

 Two quick clarifications:
 * Are we leaving the system table column the same here so that we don't have 
to do a dual get on row.getString('additional_read_policy') places like this? 
I'm just curious how we maintain changes to the table options going forward
 * Similarly are we leaving the tables outputting speculative_retry in the 
DESCRIBE calls because the various clients would need changes otherwise?

> Rename speculative_retry to match additional_write_policy
> ---------------------------------------------------------
>                 Key: CASSANDRA-14761
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14761
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Legacy/Core
>            Reporter: Ariel Weisberg
>            Assignee: Ariel Weisberg
>            Priority: Major
>             Fix For: 4.0
> It's not really speculative. This commit is where it was last named and shows 
> what to update 
> https://github.com/aweisberg/cassandra/commit/e1df8e977d942a1b0da7c2a7554149c781d0e6c3

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to