Skip to content

Allow force stopping server process#107170

Merged
elasticsearchmachine merged 4 commits intoelastic:mainfrom
rjernst:cli/kill_process
Apr 11, 2024
Merged

Allow force stopping server process#107170
elasticsearchmachine merged 4 commits intoelastic:mainfrom
rjernst:cli/kill_process

Conversation

@rjernst
Copy link
Copy Markdown
Member

@rjernst rjernst commented Apr 5, 2024

This commit allows the cli access to sending SIGKILL to the underlying jvm process.

This commit allows the cli access to sending SIGKILL to the underlying
jvm process.
@rjernst rjernst added >refactoring :Core/Infra/CLI CLI utilities, scripts, and infrastructure labels Apr 5, 2024
@rjernst rjernst requested a review from a team as a code owner April 5, 2024 20:44
@elasticsearchmachine elasticsearchmachine added v8.14.0 Team:Core/Infra Meta label for core/infra team labels Apr 5, 2024
@elasticsearchmachine
Copy link
Copy Markdown
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

Copy link
Copy Markdown
Contributor

@mosche mosche left a comment

Choose a reason for hiding this comment

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

Code looks good, just curious about the intend? Is that meant to support testing abrupt termination?
Some comments on the test, though.

};
var server = startProcess(false, false);
nonInterruptibleVoid(inMain::await);
forceStopCallback = blockMain::countDown;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Not sure I understand the intention of the forceStopCallback here, nonInterruptibleVoid(blockMain::await) will be interrupted and throw an AssertionError, counting down the latch doesn't make any difference.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

forceStop waits on the process to die. In this test, main is waiting indefinitely. Even though calling forceStop cancels the task, the thread is still alive, waiting on the latch. So without decrementing the latch, while in forceStop, the waitFor would wait indefinitely.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Even though calling forceStop cancels the task, the thread is still alive, waiting on the latch

Makes sense, though as long as the interrupt status after cancelling the thread isn't lost, blockMain.await() will be interrupted without having to count down. So a noop callback works just as well here.

forceStopCallback = blockMain::countDown;
server.forceStop();

assertThat(process.main.isDone(), is(true)); // stop should have waited
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

isCancelled instead of isDone to clarify the difference?

@rjernst
Copy link
Copy Markdown
Member Author

rjernst commented Apr 9, 2024

The intent is to allow forcing the process to stop. While we don't use it in the ServerCli, serverless has a need to quickly shutdown ES in certain circumstances where we don't want to wait for a "clean" shutdown.

Copy link
Copy Markdown
Contributor

@mosche mosche left a comment

Choose a reason for hiding this comment

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

LGTM, though would be good to use isCancelled as mentioned.

@rjernst rjernst added the auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) label Apr 10, 2024
@elasticsearchmachine elasticsearchmachine merged commit 4114eea into elastic:main Apr 11, 2024
@rjernst rjernst deleted the cli/kill_process branch April 11, 2024 00:38
craigtaverner pushed a commit to craigtaverner/elasticsearch that referenced this pull request Apr 11, 2024
This commit allows the cli access to sending SIGKILL to the underlying
jvm process.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) :Core/Infra/CLI CLI utilities, scripts, and infrastructure >refactoring Team:Core/Infra Meta label for core/infra team v8.14.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants