[
https://issues.apache.org/jira/browse/CASSANDRA-14761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767753#comment-16767753
]
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.
{quote}
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
[Java|https://docs.datastax.com/en/developer/java-driver/4.0-beta/manual/core/speculative_execution/]
/
[Python|https://datastax.github.io/python-driver/api/cassandra/policies.html?highlight=speculation]
Driver: "Speculative Execution Policy" -> {{speculative_execution_policy}}
* Jeff Dean's [Tail at
Scale|https://cseweb.ucsd.edu/~gmporter/classes/fa17/cse124/post/schedule/p74-dean.pdf]:
"Hedged requests" -> {{hedged_request_policy}}
* [Google SRE
Book|https://landing.google.com/sre/sre-book/chapters/addressing-cascading-failures/]
(which just cites Tail at Scale): "hedged requests" ->
{{hedged_request_policy}}
*
[gRPC|https://github.com/grpc/proposal/blob/master/A6-client-retries.md#limits-on-retries-and-hedges]:
"Hedging policy" -> {{hedging_policy}} or {{hedged_request_policy}}
*
[Hadoop|https://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/mapred-default.xml]:
"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" ->
{{speculative_execution_policy}}
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
options:
||Root||Read Requests||Transient Replica Upgrade / Write Requests||
|"speculation" option
1|{{speculative_read_policy}}|{{speculative_transient_write_policy}}|
|"speculation" option 2 (similar to status
quo)|{{speculative_retry}}|{{additional_transient_write_policy}}|
|"speculation" option
3|{{speculative_execution_policy}}|{{transient_write_upgrade_policy}}|
|"speculation" option
4|{{idempotent_speculative_policy}}|{{transient_speculative_policy}}|
|"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)}}
[here|https://github.com/apache/cassandra/compare/trunk...aweisberg:14761-trunk?expand=1#diff-40a2ae61c758454cc6166903250edbdfR845]
instead of adding the {{reregisterTableCounter}}
[method|https://github.com/apache/cassandra/compare/trunk...aweisberg:14761-trunk?expand=1#diff-40a2ae61c758454cc6166903250edbdfR1056]?
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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
