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

[ML] Fix simultaneous stop and force stop datafeed #49367

Merged

Conversation

droberts195
Copy link
Contributor

If a datafeed is stopped normally and force stopped at the same
time then it is possible that the force stop removes the
persistent task while the normal stop is performing actions.
Currently this causes the normal stop to error, but since
stopping a stopped datafeed is not an error this doesn't make
sense. Instead the force stop should just take precedence.

This is a followup to #49191 and should really have been
included in the changes in that PR.

If a datafeed is stopped normally and force stopped at the same
time then it is possible that the force stop removes the
persistent task while the normal stop is performing actions.
Currently this causes the normal stop to error, but since
stopping a stopped datafeed is not an error this doesn't make
sense. Instead the force stop should just take precedence.

This is a followup to elastic#49191 and should really have been
included in the changes in that PR.
@elasticmachine
Copy link
Collaborator

Pinging @elastic/ml-core (:ml)

@droberts195
Copy link
Contributor Author

Existing tests already cover the scenario that is fixed here. It was one of the backport PRs of #49191 that found the problem - the relevant Gradle scan is https://gradle-enterprise.elastic.co/s/lrofxnw6rotco and that came from a PR build of #49290.

For 7.5 and 6.8 I will incorporate the changes of this PR into the (still open) backport PRs of #49191.

Copy link
Contributor

@dimitris-athanasiou dimitris-athanasiou left a comment

Choose a reason for hiding this comment

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

LGTM

@droberts195 droberts195 merged commit e5e8fa8 into elastic:master Nov 20, 2019
@droberts195 droberts195 deleted the another_datafeed_stop_edge_case branch November 20, 2019 12:36
droberts195 added a commit that referenced this pull request Nov 20, 2019
If a datafeed is stopped normally and force stopped at the same
time then it is possible that the force stop removes the
persistent task while the normal stop is performing actions.
Currently this causes the normal stop to error, but since
stopping a stopped datafeed is not an error this doesn't make
sense. Instead the force stop should just take precedence.

This is a followup to #49191 and should really have been
included in the changes in that PR.
@droberts195
Copy link
Contributor Author

Backport to 7.x is 20558cf.

Backports to 7.5 and 6.8 are in #49286 and #49290 respectively.

droberts195 added a commit to droberts195/elasticsearch that referenced this pull request Nov 22, 2019
The problem reported in elastic#44566 should be fixed by the change
that was made in elastic#49367, so the muted test can be unmuted.

Closes elastic#44566
droberts195 added a commit that referenced this pull request Nov 22, 2019
The problem reported in #44566 should be fixed by the change
that was made in #49367, so the muted test can be unmuted.

Closes #44566
@droberts195 droberts195 added v7.5.0 and removed v7.5.1 labels Nov 26, 2019
droberts195 added a commit to droberts195/elasticsearch that referenced this pull request Jul 19, 2021
A check for this situation when closing multiple jobs or stopping
multiple datafeeds was added in elastic#38113.  Later the wildcard
requirement was removed for jobs in elastic#49367.  But the wildcard
requirement really should have been removed for both jobs and
datafeeds, as they both having the same semantics that closing
or stopping one that's already closed/stopped is not an error.

This commit removes the wildcard condition for jobs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants