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
Run TransportGetAliasesAction on local node #101815
Run TransportGetAliasesAction on local node #101815
Conversation
This action is a pure function of the cluster state, it can run on any node. Moreover it can be fairly expensive if there are a lot of aliases so running it on the master can be quite harmful to the cluster. Finally, it needs to be cancellable to avoid doing unnecessary work after a client failure or timeout.
Hi @DaveCTurner, I've created a changelog YAML for you. |
Pinging @elastic/es-data-management (Team:Data Management) |
@Override | ||
public Task createTask(long id, String type, String action, TaskId parentTaskId, Map<String, String> headers) { | ||
return new CancellableTask(id, type, action, "", parentTaskId, headers); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This (overriding createTask to return CancellableTask
) seems to be repeating a lot around the code base.
Is it possible to do it in a common base class? Possibly something like:
default Task createTask(long id, String type, String action, TaskId parentTaskId, Map<String, String> headers) {
return this instance of CancellableRequest ?
new CancellableTask(id, type, action, getDescription(), parentTaskId, headers);
new Task(id, type, action, getDescription(), parentTaskId, headers);
}
where CancellableRequest would be a new marker interface?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh maybe, it's kinda tricky when everything already derives from ActionRequest
tho. I expect #100111 will make this simpler. Not in scope here tho.
* NB prior to 8.12 this was a TransportMasterNodeReadAction so for BwC it must be registered with the TransportService (i.e. a | ||
* HandledTransportAction) until we no longer need to support {@link org.elasticsearch.TransportVersions#CLUSTER_FEATURES_ADDED} and | ||
* earlier. | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems this is going to be true for all actions from the list in the task.
Is it worth to mention it once in TransportLocalClusterStateAction
and ideally have a constant that would let us know when to remove HandledTransportAction
base from there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt we'll get all of them done by the time v9 is released, so I'd rather keep it a case-by-case thing.
server/src/main/java/org/elasticsearch/action/admin/indices/alias/get/GetAliasesRequest.java
Show resolved
Hide resolved
In elastic#101815 we made some changes to the get-aliases API that need followup actions when preparing to release v9. At the time they were marked with a transport version that will become obsolete in v9, but with elastic#101767 we now have a better mechanism for leaving a reminder for this kind of action. This commit updates things to use the new @UpdateForV9 annotation instead.
In elastic#101815 we made some changes to the get-aliases API that need followup actions when preparing to release v9. At the time they were marked with a transport version that will become obsolete in v9, but with elastic#101767 we now have a better mechanism for leaving a reminder for this kind of action. This commit updates things to use the new @UpdateForV9 annotation instead.
This action is a pure function of the cluster state, it can run on any
node. Moreover it can be fairly expensive if there are a lot of aliases
so running it on the master can be quite harmful to the cluster.
Finally, it needs to be cancellable to avoid doing unnecessary work
after a client failure or timeout.
Relates #101805