-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Use system context for cluster state update tasks #31241
Changes from 1 commit
7ec662f
1b7eeb4
e205ad2
7b92bdb
faf152c
44e8d90
d70d73a
8b8e3e3
29a0552
2a9c6a9
6c22141
7c83153
9c036a5
f5ca4d9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -346,8 +346,8 @@ public void onFailure(String source, Exception e) { | |
} | ||
|
||
@Override | ||
public void clusterStatePublished(ClusterChangedEvent clusterChangedEvent) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if ClusterStateUpdateTask should have a final empty method for this? I think it's always the wrong one in that contex.t There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like this idea, I've pushed 1b7eeb4 to implement this. |
||
afterClusterStateUpdate(clusterChangedEvent.state(), request); | ||
public void clusterStateProcessed(String source, ClusterState oldState, ClusterState newState) { | ||
afterClusterStateUpdate(newState, request); | ||
actionListener.onResponse(new PutJobAction.Response(updatedJob.get())); | ||
} | ||
}); | ||
|
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.
instead of doing this, I wonder if we should invest in a SystemThreadContext that we give to the executor and it does is under the system context. Alternatively we can have a "no context" executor that simply doesn't set any context. @tvernum do you see any other usage for this?
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'm not sure if I understand this correctly. Would you have different executors based on whether they switch to the system context or stay in default context? Looking at the other usages of
threadContext.markAsSystemContext();
, all of them seem to use executors that cannot be categorized as system or non-system (i.e. generic threadpool, ...).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.
my suggestion referred to the entire pattern of generating a new context and then marking it as system and deal with on the executor level. This has two potential upsides:
Since this is not a high throughput usage and we only have one place we submit tasks it doesn't have such a big impact on
MasterService
but might be useful for other things that use an internal thread pool executor.