-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Include empty servers in BrokerServerView. #18200
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
Changes from all commits
aa6ed8c
1253135
ae76084
6539526
1928bf7
a4645de
3ba976f
ef41058
0741a22
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 |
|---|---|---|
|
|
@@ -157,11 +157,25 @@ public CallbackAction segmentSchemasAnnounced(SegmentSchemas segmentSchemas) | |
| segmentFilter | ||
| ); | ||
|
|
||
| baseView.registerServerRemovedCallback( | ||
| baseView.registerServerCallback( | ||
| exec, | ||
| server -> { | ||
| removeServer(server); | ||
| return CallbackAction.CONTINUE; | ||
| new ServerCallback() { | ||
| @Override | ||
| public CallbackAction serverAdded(DruidServer server) | ||
| { | ||
| // We don't track brokers in this view. | ||
| if (!server.getType().equals(ServerType.BROKER)) { | ||
|
Contributor
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. Please add a 1-liner comment like "Do not keep inventory of other Brokers" or something.
Contributor
Author
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. Added a comment
Contributor
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. Thanks! |
||
| addServer(server); | ||
| } | ||
| return CallbackAction.CONTINUE; | ||
|
Contributor
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. Do we ever use the other callback action
Contributor
Author
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. It's not used, & seems like it hasn't been used since #6742. I suppose we could remove it in this PR or in a new one. |
||
| } | ||
|
|
||
| @Override | ||
| public CallbackAction serverRemoved(DruidServer server) | ||
| { | ||
| removeServer(server); | ||
| return CallbackAction.CONTINUE; | ||
| } | ||
| } | ||
| ); | ||
| } | ||
|
|
@@ -378,9 +392,9 @@ public <T> QueryRunner<T> getQueryRunner(DruidServer server) | |
| } | ||
|
|
||
| @Override | ||
| public void registerServerRemovedCallback(Executor exec, ServerRemovedCallback callback) | ||
| public void registerServerCallback(Executor exec, ServerCallback callback) | ||
| { | ||
| baseView.registerServerRemovedCallback(exec, callback); | ||
| baseView.registerServerCallback(exec, callback); | ||
| } | ||
|
|
||
| @Override | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -29,7 +29,7 @@ | |
| */ | ||
| public interface ServerView | ||
| { | ||
| void registerServerRemovedCallback(Executor exec, ServerRemovedCallback callback); | ||
| void registerServerCallback(Executor exec, ServerCallback callback); | ||
|
Contributor
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. Super nit: To allow for more concise syntax (using lambdas) in the calling code, I wonder if we should have an overloaded method with the signature: void registerServerCallback(Executor exec, Consumer<DruidServer> onAdded, Consumer<DruidServer> onRemoved);assuming we get rid of the
It might be useful even when we add new methods to
Contributor
Author
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. A builder might be nice too. It would allow keeping together all the ServerCallback.builder()
.onServerAdded(server -> ...)
.onServerRemoved(server -> ...)
.build()or for just doing one: ServerCallback.onServerRemoved(server -> ...)etc. Would like to have this be a different PR, so that PR can focus on the thinking about the best way to specify callbacks that only want to listen to one thing. |
||
| void registerSegmentCallback(Executor exec, SegmentCallback callback); | ||
|
|
||
| enum CallbackAction | ||
|
|
@@ -38,8 +38,24 @@ enum CallbackAction | |
| UNREGISTER, | ||
| } | ||
|
|
||
| interface ServerRemovedCallback | ||
| interface ServerCallback | ||
| { | ||
| /** | ||
| * Called when a server is added. | ||
| * | ||
| * The return value indicates if this callback has completed its work. Note that even if this callback | ||
| * indicates that it should be unregistered, it is not possible to guarantee that this callback will not | ||
| * get called again. There is a race condition between when this callback runs and other events that can cause | ||
| * the callback to be queued for running. Thus, callbacks shouldn't assume that they will not get called | ||
| * again after they are done. The contract is that the callback will eventually be unregistered, enforcing | ||
| * a happens-before relationship is not part of the contract. | ||
| * | ||
| * @param server The server that was added. | ||
| * @return UNREGISTER if the callback has completed its work and should be unregistered. CONTINUE if the callback | ||
| * should remain registered. | ||
| */ | ||
| CallbackAction serverAdded(DruidServer server); | ||
|
|
||
| /** | ||
| * Called when a server is removed. | ||
| * | ||
|
|
||
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.
Nit: Probably cleaner to use
Map.forEach.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.
Personally, I prefer the regular
forin situations where theforEachcan't be a one-liner (& even sometimes then) so I kept it as-is.