-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[improve][broker] Make ExtensibleLoadManagerImpl's broker filter pure async #20666
[improve][broker] Make ExtensibleLoadManagerImpl's broker filter pure async #20666
Conversation
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.
+1
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.
hi, i left some comments here 👋
return CompletableFuture.completedFuture(Optional.empty()); | ||
CompletableFuture<Map<String, BrokerLookupData>> future = | ||
filter.filter(availableBrokerCandidates, bundle, context); | ||
futures.add(future); |
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.
do we need process order for the filter here. the k8s scheduler will apply filter orderly. I wonder if we need it.
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.
No, we do no need to guarantee the order.
CompletableFuture<Optional<String>> result = new CompletableFuture<>(); | ||
FutureUtil.waitForAll(futures).whenComplete((__, ex) -> { | ||
if (ex != null) { | ||
log.error("Failed to filter out brokers when select bundle: {}", bundle, ex); |
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.
It seems we ignore all the filter result exception here. does this will inference the filter logic ? or we can choose some soft limit filter exception can be ignored and some filter are not.
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.
afaik, I think this is the current behavior in the modular load manager. I think we can add a todo or a backlog issue to follow up.
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.
Yes, I added todo comment here.
pulsar-broker/src/main/java/org/apache/pulsar/broker/loadbalance/impl/LoadManagerShared.java
Outdated
Show resolved
Hide resolved
pulsar-broker/src/main/java/org/apache/pulsar/broker/loadbalance/impl/LoadManagerShared.java
Outdated
Show resolved
Hide resolved
pulsar-broker/src/main/java/org/apache/pulsar/broker/loadbalance/impl/LoadManagerShared.java
Outdated
Show resolved
Hide resolved
@@ -53,6 +54,20 @@ private Optional<NamespaceIsolationPolicies> getIsolationPolicies(String cluster | |||
} | |||
} | |||
|
|||
private CompletableFuture<Optional<NamespaceIsolationPolicies>> getIsolationPoliciesAsync(String clusterName) { | |||
return this.pulsar.getPulsarResources().getNamespaceResources() | |||
.getIsolationPolicies().getIsolationDataPoliciesAsync(clusterName); |
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 the callback of this CompletableFuture is still execute on the metadataStore thread. if yes, if switch callback execute thread to other thread is needed ? WDYT?
CompletableFuture<Optional<String>> result = new CompletableFuture<>(); | ||
FutureUtil.waitForAll(futures).whenComplete((__, ex) -> { | ||
if (ex != null) { | ||
log.error("Failed to filter out brokers when select bundle: {}", bundle, ex); |
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.
afaik, I think this is the current behavior in the modular load manager. I think we can add a todo or a backlog issue to follow up.
@@ -477,7 +477,7 @@ public CompletableFuture<Optional<String>> selectAsync(ServiceUnitId bundle, | |||
Set<String> excludeBrokerSet) { | |||
BrokerRegistry brokerRegistry = getBrokerRegistry(); | |||
return brokerRegistry.getAvailableBrokerLookupDataAsync() | |||
.thenCompose(availableBrokers -> { | |||
.thenComposeAsync(availableBrokers -> { |
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.
@lifepuzzlefun I think we can switch a thread here.
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.
agree
173503a
to
1447f41
Compare
Codecov Report
@@ Coverage Diff @@
## master #20666 +/- ##
============================================
+ Coverage 72.60% 73.06% +0.46%
- Complexity 32018 32110 +92
============================================
Files 1855 1871 +16
Lines 138569 139056 +487
Branches 15250 15305 +55
============================================
+ Hits 100605 101605 +1000
+ Misses 29945 29399 -546
- Partials 8019 8052 +33
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
LGTM
Do we need to cherry pick to 3.0.2? |
@Technoboy- Yes |
Map<String, BrokerLookupData> filter(Map<String, BrokerLookupData> brokers, | ||
ServiceUnitId serviceUnit, | ||
LoadManagerContext context) | ||
throws BrokerFilterException; | ||
CompletableFuture<Map<String, BrokerLookupData>> filter(Map<String, BrokerLookupData> brokers, | ||
ServiceUnitId serviceUnit, | ||
LoadManagerContext context); |
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.
We should not cherry-pick this public API change to branch-3.0 @Demogorgon314
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 method has yet to be exposed to users. In this case, can we cherry-pick?
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.
@BewareMyPower I pushed a PR to add the broker filter sync method back: #20826. Is this way acceptable?
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.
Yes. It's okay. But since a new method is added into the BrokerFilter
, we should still avoid cherry-picking it to release branches.
Motivation
Currently, the filter has some block methods, e.g.,
getIsolationDataPolicies
method. When calling the block method in the metadata-store thread, it might cause a deadlock. For more detail, see: #20130Modifications
Documentation
doc
doc-required
doc-not-needed
doc-complete
Matching PR in forked repository
PR in forked repository: