[
https://issues.apache.org/jira/browse/CASSANDRA-14761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685471#comment-16685471
]
Ariel Weisberg commented on CASSANDRA-14761:
--------------------------------------------
bq. As a user I find this new naming pretty confusing, and I'm curious what
other users think. I think there is significant mind-share in the community and
indeed other distributed systems (e.g. hadoop) around the concept of
speculative execution of idempotent operations. If anything I think it makes
sense to do speculative_read_policy and speculative_transient_write_policy.
Even if we keep the additional_read_policy and additional_write_policy naming I
worry a user could easily confuse these somewhat different features (I know
that I was confused at first).
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.
bq. I think most of the failing dtests are coming from the unconditional check
that the objects are equal even if one isn't set. Perhaps only check they are
equal if they are both set?. Also the string format swaps speculativeRetry with
additionReadPolicy (which should probably be additional).
I'll work on the dtests now.
bq. Did you mean to remove the speculative read option? I think you would want
both additional_write and additional_read in the table?
Yes it's intentional. People shouldn't use the old option. I should add a line
saying that it existed so people are aware one replaces the other.
bq. If I understand speculative transient replica upgrade right, this text no
longer applies to just read coordinators.
Good point I'll update.
bq. AdditionalReadsFailed appears to be inconsistent with the other new in 4.0
metrics (SpeculativeInsufficientRetries and SpeculativeSampleLatencyNanos).
Personally I like the Speculative name across the board (esp since if we change
SpeculativeRetries it's not backwards compatible).
Everything we are doing here should be 100% backwards compatible. It's why the
metric is registered under both old and new names.
I must have had a really bad day because there is a bunch of metric
registration that looks mixed up to me. I'll do a patch to fix the bugs and
make it consistent.
> 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: 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
