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

Use a dedicated test executor in MockTransportService #112748

Merged
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,8 @@
import org.elasticsearch.common.util.CollectionUtils;
import org.elasticsearch.common.util.MockPageCacheRecycler;
import org.elasticsearch.common.util.concurrent.AbstractRunnable;
import org.elasticsearch.common.util.concurrent.EsExecutors;
import org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor;
import org.elasticsearch.common.util.concurrent.RunOnce;
import org.elasticsearch.core.AbstractRefCounted;
import org.elasticsearch.core.IOUtils;
Expand Down Expand Up @@ -206,6 +208,7 @@ public static MockTransportService getInstance(String nodeName) {
}

private final Transport original;
private final EsThreadPoolExecutor testExecutor;

/**
* Build the service.
Expand Down Expand Up @@ -302,6 +305,16 @@ private MockTransportService(
Tracer.NOOP
);
this.original = transport.getDelegate();
this.testExecutor = EsExecutors.newScaling(
"mock-transport",
0,
4,
30,
TimeUnit.SECONDS,
false,
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we set rejectAfterShutdown to true please?

Copy link
Member Author

Choose a reason for hiding this comment

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

I pondered on this and decided to use false to align with how the generic executor is defined. I also think it might be better to let the "real" executors to decide whether task should be rejected, i.e. if the task has reached here, it is not rejected and we should just queue it up. That said, I am OK with true as well since it was my initial preference for better predictability. See 63a4614

Copy link
Contributor

Choose a reason for hiding this comment

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

it is not rejected and we should just queue it up

Sure but that's not what false does, it just silently drops any work submitted after shutdown.

My thinking here is twofold: firstly, we are terminating this ExecutorService at the end of the test, there should be no more tasks submitted by that point anyway. Secondly, IMO the silent-drop behaviour of generic after shutdown is a bug, even if it is unfortunately one we cannot easily address without changing lots of other things, but we can at least avoid relying on that same behaviour in specific situations like this one.

Copy link
Member Author

Choose a reason for hiding this comment

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

but that's not what false does, it just silently drops any work submitted after shutdown.

TIL. Thanks!

EsExecutors.daemonThreadFactory("mock-transport"),
threadPool.getThreadContext()
);
}

private static TransportAddress[] extractTransportAddresses(TransportService transportService) {
Expand Down Expand Up @@ -617,7 +630,7 @@ protected void doRun() throws IOException {
delay
)
);
threadPool.schedule(runnable, delay, threadPool.generic());
threadPool.schedule(runnable, delay, testExecutor);
}
}
}
Expand Down Expand Up @@ -795,6 +808,8 @@ protected void doClose() throws IOException {
}
} catch (InterruptedException e) {
throw new IllegalStateException(e);
} finally {
ThreadPool.terminate(testExecutor, 10, TimeUnit.SECONDS);
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we have an assertTrue here to make sure it did actually terminate?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep see 63a4614

}
}

Expand Down