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

Zen2: Add node id to log output of CoordinatorTests #33929

Merged
merged 4 commits into from
Sep 21, 2018

Conversation

ywelsch
Copy link
Contributor

@ywelsch ywelsch commented Sep 21, 2018

With recent changes to the logging framework, the node name can no longer be injected into the logging output using the node.name setting, which means that for the CoordinatorTests (which are simulating a cluster in a fully deterministic fashion using a single thread), as all the different nodes are running under the same test thread, we are not able to distinguish which log lines are coming from which node. This PR readds logging for node ids in the CoordinatorTests, making two very small changes to DeterministicTaskQueue and TestThreadInfoPatternConverter.

@ywelsch ywelsch added >non-issue v7.0.0 :Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. labels Sep 21, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

return runnable -> runnableConsumer.accept(wrap(runnable, node));
}

private static Function<Runnable, Runnable> wrapper(DiscoveryNode node) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think I'd inline this, it's only used in one place.

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

Very neat. I asked for two minor changes. Also can you think of a way to get the node name into the same place in these DeterministicTaskQueue messages:

running task n of m
advanceTime: no longer deferred

I see that it's there at the end:

... (wrapped for {node0}{hI1aFgAAQACTyUPC_____w}{0.0.0.0}{0.0.0.0:1})

but just wondered if it was possible to get it to the start as well.

@@ -364,4 +367,28 @@ private static void processMessageReceived(TransportRequest request, RequestHand
TransportChannel transportChannel) throws Exception {
requestHandler.processMessageReceived(request, transportChannel);
}

private static Consumer<Runnable> wrap(Consumer<Runnable> runnableConsumer, DiscoveryNode node) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think I'd inline this, it's only used in one place.

return runnable -> wrap(runnable, node);
}

private static Runnable wrap(Runnable runnable, DiscoveryNode node) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could this be onNode(DiscoveryNode node, Runnable runnable) - makes it a bit more readable at its call sites?

@ywelsch
Copy link
Contributor Author

ywelsch commented Sep 21, 2018

Also can you think of a way to get the node name into the same place in these DeterministicTaskQueue messages:

The only possibility I see for doing this would be to extend the notion of task on DeterministicTaskQueue. I'm not sure we should do that though if we can get away with something simpler. The DeterministicTaskQueue is more of a global object (rather than a per-node level object). Maybe it's sufficient to change runnable.toString() + " (wrapped for " + node + ")" to node + ": " + runnable.toString (), i.e., change the order so that the node name appears earlier?

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

I think I'd have preferred to keep DisruptableMockTransport out of this, or to introduce it first in a separate change, although I see the benefits. Asked for a couple more changes.

@@ -379,7 +297,7 @@ public void run() {

@Override
public String toString() {
return runnable.toString() + " (wrapped for " + node + ")";
return node.getId() + ": " + runnable.toString();
Copy link
Contributor

Choose a reason for hiding this comment

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

I think that having the UUID of the disco node will be useful here when we start rebooting nodes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've added the ephemeral id

private static void processMessageReceived(TransportRequest request, RequestHandlerRegistry requestHandler,
TransportChannel transportChannel) throws Exception {
requestHandler.processMessageReceived(request, transportChannel);
private static Runnable onNode(Runnable runnable, DiscoveryNode node) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I meant to put the DiscoveryNode thing first, otherwise it ends up a long way from the function call if the Runnable is an anonymous class.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok. With the recent changes, there were no longer any anonymous classes. I've still changed the order

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

Great, LGTM.

@ywelsch ywelsch changed the title Add node id to log output of CoordinatorTests Zen2: Add node id to log output of CoordinatorTests Sep 21, 2018
@ywelsch ywelsch merged commit a612dd1 into elastic:zen2 Sep 21, 2018
@ywelsch
Copy link
Contributor Author

ywelsch commented Sep 21, 2018

I've run this locally on my CI

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. >non-issue v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants