[
https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17792103#comment-17792103
]
Alex Petrov commented on CASSANDRA-19009:
-----------------------------------------
[~bdeggleston] thank you for the updates!
It looks like updates currently work by essentially submitting an update after
delay. If one more update is coming and it spercedes the previous update (here
this only means that its status is different), we will check if DELAY has
elapsed since we have last updated it, and will update if yes.
I would suggest to approach this a bit differently. I think we can actually can
both reduce a number of futures, and avoid waiting for the delay for
reconfiguration. Once we have determined there's a state change, I think we can
simply check if the {{DELAY}} has passed after the last update and this is an
effective state change (ie new value will be different from the old one, just
as you do right now), we can simply submit the transformation. In
transformation, however, we now will have {{shouldUpdateFastPath}} logic: we
will check that {{DELAY}} has elapsed (i think it's ok if the delay is provided
by the submitting node) since last update till {{updateTimeMillis}} and that
{{status}} is now some new value, and will return {{REJECTED}} otherwise. Since
TCM handles retries itself, you do not have to worry about anything else.
Thing is, transformation will make it into the log only in case it actually
makes a change (i.e. it is a success). Rejected transformations are not
persisted.
Just to highlight, without duplicating the {{shouldUpdateFastPath}} logic on
submitter and in transformation will cause higher load on the CMS for paxos
reads, since multiple nodes may see state changes simulataneously.
And several small nits:
* {{normalIds}} is currently unused; but if we were to use it might be worth
to add {{isNormal}} rather then checking against enum value
* {{shouldUpdateFastPath}} already node info, now millis and delay millis, i
think we do not need to pass it again (but I think if you go with the approach
suggested above this will naturally change)
* {{getAccordFastPathUpdateDelayMillis}} - since this technically not a
delay, it is rather shortest interval between updates.
> CEP-15: (C*/Accord) Schema based fast path reconfiguration
> -----------------------------------------------------------
>
> Key: CASSANDRA-19009
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19009
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Priority: Normal
> Fix For: 5.0.x
>
>
> This adds availability aware accord fast path reconfiguration, as well as
> user configurable fast path settings, which are set at the keyspace level and
> (optionally) at the table level for increased granularity.
> The major parts are:
> *Add availability information to cluster metadata*
> Accord topology in C* is not stored in cluster metadata, but is meant to
> calculated deterministically from cluster metadata state at a given epoch.
> This adds the availability data, as well as the failure detector / gossip
> listener and state change deduplication to CMS.
> *Move C* accord keys/topology from keyspace prefixes to tableid prefixes*
> To support per-table fast path settings, topologies and keys need to include
> the table id. Since accord topologies could begin to consume a lot of memory
> in clusters with a lot of nodes and tables, topology generation has been
> updated to reuse previously allocated shards / shard parts where possible,
> which will only increase heap sizes when things actually change.
> *Make fast path settings configurable via schema*
> There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings.
> Simple will use as many available nodes as possible for the fast path
> electorate, this is the default for the keyspace fast path strategy.
> Parameterized allows you to set a target size, and preferred datacenters for
> the FP electorate. InheritKeyspace tells topology generation to just use the
> keyspace fast path settings, and is the default for the table fast path
> strategy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
