[
https://issues.apache.org/jira/browse/CASSANDRA-15935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213799#comment-17213799
]
Alex Petrov edited comment on CASSANDRA-15935 at 10/14/20, 10:16 AM:
---------------------------------------------------------------------
Moving a
[conversation|https://github.com/apache/cassandra/pull/759#discussion_r503611334]
about {{Action}} vs static method here.
bq. in your examples there are no real differences between run and forEach, so
I rather have forEach only.
You're right there are no real differences between {{run}} and {{forEach}}.
However, I had several reasons to use interface implementaions, which are:
1. {{Action}} is an atomic unit of logic, unlike a static method. You can
immediately see all things related to a specific action, reuse, and move then
at your discression. Using static methods will quickly get out of hand when we
have more sophisticated actions.
2. Separation of input arguments (for example "disseminate gossip state of the
node X") and `target`, making `target` explicit and common for all cases. In
some cases, we can even reduce amount of work we're doing, and do it once in a
constructor. For example,
[here|https://github.com/ifesdjeen/cassandra/blob/96eab42347f51bd32a22875b85f4acf6cd9785d4/test/distributed/org/apache/cassandra/distributed/action/GossipHelper.java#L136-L144],
we create gossip state that gets disseminated by getting applied to each
action. Contrast this with
[this|https://github.com/dcapwell/cassandra/blob/935f78b101484f6dfee473fd5375a31761f02b39/test/distributed/org/apache/cassandra/distributed/action/GossipHelper.java#L122-L143],
where we either have to change to use instance collection as input, or
re-create distributed state each time.
3. Main idea behind the `Action` was to create reusable pieces of logic you can
apply to cluster or nodes. For now, logic is simple, like "pull schema fom X,
and then bootstrap", but we can reuse similar sequences of steps in:
a. Harry, where we can schedule different actions against different sets of
nodes, producing reliable results
b. In upgrade test, where you'll be able to run named actions aginst
instances despite the fact they have different versions.
To do (a) and (b) with static methods, we'll have to _still_ implement some
interface.
4. We can use static code analysis to find all Actions in the code.
5. We can chain actions, too:
{code}
cluster.run(asList(pullSchemaFrom(cluster.get(1)),
bootstrap()),
newInstance.config().num());
{code}
I've used {{Action}} from the beginning with these intention. Everyone I asked
has no strong preference towards on or the other, and it's same with me: aside
from the above arguments, difference is purely syntactic. Both approaches have
equivalent semantics.
was (Author: ifesdjeen):
Moving a
[conversation|https://github.com/apache/cassandra/pull/759#discussion_r503611334]
about {{Action}} vs static method here.
bq. in your examples there are no real differences between run and forEach, so
I rather have forEach only.
You're right there are no real differences between {{run}} and {{forEach}}.
However, I had several reasons to use interface implementaions, which are:
1. {{Action}} is an atomic unit of logic, unlike a static method. You can
immediately see all things related to a specific action, reuse, and move then
at your discression. Using static methods will quickly get out of hand when we
have more sophisticated actions.
2. Separation of input arguments (for example "disseminate gossip state of the
node X") and `target`, making `target` explicit and common for all cases.
3. Main idea behind the `Action` was to create reusable pieces of logic you can
apply to cluster or nodes. For now, logic is simple, like "pull schema fom X,
and then bootstrap", but we can reuse similar sequences of steps in:
a. Harry, where we can schedule different actions against different sets of
nodes, producing reliable results
b. In upgrade test, where you'll be able to run named actions aginst
instances despite the fact they have different versions.
To do (a) and (b) with static methods, we'll have to _still_ implement some
interface.
4. In some cases, we can just reduce amount of work we're doing. For example,
[here|https://github.com/ifesdjeen/cassandra/blob/96eab42347f51bd32a22875b85f4acf6cd9785d4/test/distributed/org/apache/cassandra/distributed/action/GossipHelper.java#L136-L144],
we create gossip state that gets disseminated by getting applied to each
action. Contrast this with
[this|https://github.com/dcapwell/cassandra/blob/935f78b101484f6dfee473fd5375a31761f02b39/test/distributed/org/apache/cassandra/distributed/action/GossipHelper.java#L122-L143],
where we either have to change to use instance collection as input, or
re-create distributed state each time.
5. We can use static code analysis to find all Actions in the code.
6. We can chain actions, too:
{code}
cluster.run(asList(pullSchemaFrom(cluster.get(1)),
bootstrap()),
newInstance.config().num());
{code}
I've used {{Action}} from the beginning with these intention. Everyone I asked
has no strong preference towards on or the other, and it's same with me: aside
from the above arguments, difference is purely syntactic. Both approaches have
equivalent semantics.
> Improve machinery for testing consistency in presence of range movements
> ------------------------------------------------------------------------
>
> Key: CASSANDRA-15935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15935
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
> Reporter: Alex Petrov
> Assignee: Alex Petrov
> Priority: Normal
>
> Currently, we can test range movements only by adding and bootstrapping a new
> node. This is both inefficient and insufficient for large-scale tests. We
> need a possibility to dynamically change ring ownership over the lifetime of
> cluster, with a flexibility to changing gossip status of the node from
> perspective of other participants, adding and removing nodes from other
> nodes' views on demand.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
