[ML] Make controller send responses for each command received #1520
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change makes the controller process respond to each command it receives with a document indicating whether that command was successfully executed or not. This response will be used by the Java side of the connection to determine when it is appropriate to move on to the next phase of the action that the controller command was part of. For example, when starting a process and connecting named pipes to it it is best that the named pipe connections are not attempted until the process is confirmed to be started. Relates elastic/elasticsearch#62823
By writing results in an array it's possible to reuse the Java ProcessResultsParser class to read them. Also, making the output thread safe will make implementing elastic#1503 easier if that's ever done.
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Oct 12, 2020
This change makes threads that send a command to the ML controller process wait for it to respond to the command. Previously such threads would block until the command was sent, but not until it was actioned. This was on the assumption that the sort of commands being sent would be actioned almost instantaneously, but that assumption has been shown to be false when anti-malware software is running. Relates elastic/ml-cpp#1520 Fixes elastic#62823
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Oct 13, 2020
This is to allow merging of elastic/ml-cpp#1520 and elastic#63542 without causing every single CI build to fail. These changes will be reverted in elastic#63542 after downloadable snapshots containing the changes of elastic/ml-cpp#1520 are available.
droberts195
added a commit
to droberts195/ml-cpp
that referenced
this pull request
Oct 13, 2020
This change makes the controller process respond to each command it receives with a document indicating whether that command was successfully executed or not. This response will be used by the Java side of the connection to determine when it is appropriate to move on to the next phase of the action that the controller command was part of. For example, when starting a process and connecting named pipes to it it is best that the named pipe connections are not attempted until the process is confirmed to be started. Backport of elastic#1520
This was referenced Oct 13, 2020
droberts195
added a commit
to elastic/elasticsearch
that referenced
this pull request
Oct 16, 2020
This is to allow merging of elastic/ml-cpp#1520 and #63542 without causing every single CI build to fail. These changes will be reverted in #63542 after downloadable snapshots containing the changes of elastic/ml-cpp#1520 are available.
droberts195
added a commit
to elastic/elasticsearch
that referenced
this pull request
Oct 16, 2020
This is to allow merging of elastic/ml-cpp#1520 and #63542 without causing every single CI build to fail. These changes will be reverted in #63542 after downloadable snapshots containing the changes of elastic/ml-cpp#1520 are available. Backport of #63610
|
retest |
droberts195
added a commit
that referenced
this pull request
Oct 17, 2020
…1534) This change makes the controller process respond to each command it receives with a document indicating whether that command was successfully executed or not. This response will be used by the Java side of the connection to determine when it is appropriate to move on to the next phase of the action that the controller command was part of. For example, when starting a process and connecting named pipes to it it is best that the named pipe connections are not attempted until the process is confirmed to be started. Backport of #1520
droberts195
added a commit
to elastic/elasticsearch
that referenced
this pull request
Oct 17, 2020
This change makes threads that send a command to the ML controller process wait for it to respond to the command. Previously such threads would block until the command was sent, but not until it was actioned. This was on the assumption that the sort of commands being sent would be actioned almost instantaneously, but that assumption has been shown to be false when anti-malware software is running. Relates elastic/ml-cpp#1520 Fixes #62823
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change makes the controller process respond to each command
it receives with a document indicating whether that command was
successfully executed or not.
This response will be used by the Java side of the connection to
determine when it is appropriate to move on to the next phase of
the action that the controller command was part of. For example,
when starting a process and connecting named pipes to it it is
best that the named pipe connections are not attempted until the
process is confirmed to be started.
Relates elastic/elasticsearch#62823
Relates elastic/elasticsearch#63542