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

[Transform] Improve robustness when saving state #62086

Merged
merged 21 commits into from
Sep 28, 2020

Conversation

hendrikmuhs
Copy link

@hendrikmuhs hendrikmuhs commented Sep 8, 2020

refactor how state is persisted, call doSaveState only from the indexer thread, except there is none.

fixes #60781
fixes #52931
fixes #51629
fixes #52035

@hendrikmuhs hendrikmuhs added >test Issues or PRs that are addressing/adding tests >refactoring v8.0.0 :ml/Transform Transform v7.10.0 labels Sep 8, 2020
@hendrikmuhs hendrikmuhs marked this pull request as ready for review September 10, 2020 13:47
@elasticmachine
Copy link
Collaborator

Pinging @elastic/ml-core (:ml/Transform)

@hendrikmuhs hendrikmuhs force-pushed the transform-saveState branch 3 times, most recently from 37e71c2 to 6f77dac Compare September 14, 2020 07:45
@benwtrent benwtrent self-requested a review September 14, 2020 11:33
@hendrikmuhs
Copy link
Author

Thanks @przemekwitek and @benwtrent, I addressed your comments.

Copy link
Contributor

@przemekwitek przemekwitek left a comment

Choose a reason for hiding this comment

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

LGTM

I've left one small comment but there is no need for another review.

@hendrikmuhs
Copy link
Author

run elasticsearch-ci/bwc

@hendrikmuhs
Copy link
Author

run elasticsearch-ci/2

@hendrikmuhs
Copy link
Author

run elasticsearch-ci/packaging-sample-windows

Copy link
Member

@benwtrent benwtrent 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 all the branches are covered.

Not a huge fan of a latch away within a sync block. But, this distributed synchronizing of 3 separate mutable state values is getting out of hand.

Our testing should catch any weird conditions over time.

@hendrikmuhs
Copy link
Author

run elasticsearch-ci/bwc
run elasticsearch-ci/default-distro
run elasticsearch-ci/packaging-sample-windows

@hendrikmuhs
Copy link
Author

run elasticsearch-ci/bwc
run elasticsearch-ci/default-distro

@hendrikmuhs
Copy link
Author

run elasticsearch-ci/2

@hendrikmuhs
Copy link
Author

run elasticsearch-ci/1
run elasticsearch-ci/2

3 similar comments
@hendrikmuhs
Copy link
Author

run elasticsearch-ci/1
run elasticsearch-ci/2

@hendrikmuhs
Copy link
Author

run elasticsearch-ci/1
run elasticsearch-ci/2

@hendrikmuhs
Copy link
Author

run elasticsearch-ci/1
run elasticsearch-ci/2

@hendrikmuhs
Copy link
Author

run elasticsearch-ci/1
run elasticsearch-ci/2

(one last round :-) )

*/
final void setStopAtCheckpoint(boolean shouldStopAtCheckpoint, ActionListener<Void> shouldStopAtCheckpointListener) {
// this should be called from the generic threadpool
assert Thread.currentThread().getName().contains(ThreadPool.Names.GENERIC);
Copy link
Member

Choose a reason for hiding this comment

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

In testing (or where assertions are enabled), this would cause the caller to freeze and never return.

I am not sure how to assert here AND fire an onFailure result. But, not doing so might cause some frustrating test investigations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment