Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CASSANDRA-15319 against 2.2 #354

Closed

Conversation

jonmeredith
Copy link
Contributor

Jon Meredith and others added 12 commits September 8, 2019 15:45
The current test relies on the order of nodes returned by the snitch
to include node3, which SimpleSnitch does.  With support for other
snitches coming then the test should be able to handle any order
of nodes - so make sure all nodes are present.
And can now simplify the constructor.
Resolves issue with trying to call getMessagingVersion on nodes
that are not started, will test if it causes problems with
mixed version upgrades once all branches are updated.
this.thread = thread;
}

static TraceEntry fromObjects(Object[] objects)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The method name doesn't clearly convey the use of the method. Could we call this something different? This method converts a row result (list of deserialized objects) to a trace entry. Perhaps call this fromRowResultObjects()? I'm open to other name suggestions too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed to fromResultObjects are requested.

Copy link
Contributor

@ifesdjeen ifesdjeen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the patch, and sorry for the longer turnaround.

I've reviewed and it looks good. I only wanted to suggest, since we're using consecutive numbers anyways, to switch from using a map to the array, which slightly simplifies the code. To make sure this suggestion is right, I've tried to implement in myself in a branch [1], but please feel free to ignore my implementation.

There is a couple more minor things: imports, error message in the assert, and a removing the extra initialisation code in one of the tests.

[1] ifesdjeen@b556a46

if (nodeIdTopology.isEmpty())
throw new IllegalStateException("Topology is empty. It must have an entry for every nodeId.");

IntStream.rangeClosed(1, nodeIdTopology.size()).forEach(nodeId -> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that this really matters here, but why should we use stream here instead of a simple for loop? I really see no advantages.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It just seemed more concise than the for loop in somewhere that wasn't performance sensitive, but I'm still finding my way with appropriate use of streams.

throw new IllegalStateException("Cluster must have at least one node");

if (nodeIdTopology == null)
nodeIdTopology = IntStream.rangeClosed(1, nodeCount).boxed()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here. I might be just thinking a bit old-school)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same reasoning as above.

@jonmeredith
Copy link
Contributor Author

Thanks @ifesdjeen, I do like that the change reduces a possible source of user error of leaving gaps in the nodeId sequence, but I guard against that with an explicit runtime check.

The reason I use the map approach is so that if a user wants, they can specify exactly where each node is, so they know where cluster.coordinator(nodeId) runs from as they specified it, rather than having to either know that nodeIds are allocated in the order added and I think that gives tests a bit more clarity as to how things are allocated when the test needs more detail than the withXXX calls provide (or they don't want to iterate over the nodes to find where things are).

@ifesdjeen
Copy link
Contributor

All right. My thinking was that since we have a stream API for filtering / finding specific nodes in rack/datacenter, people would probably use those, so there is no need to expose internal identifiers. However, I'm not insisting, just elaborating on my thinking when I was suggesting this.

@jonmeredith
Copy link
Contributor Author

Committed as 58a5ce1

@jonmeredith jonmeredith closed this Oct 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants