lifepuzzlefun commented on code in PR #20512:
URL: https://github.com/apache/pulsar/pull/20512#discussion_r1225004564
##########
pulsar-broker/src/main/java/org/apache/pulsar/broker/loadbalance/impl/ModularLoadManagerImpl.java:
##########
@@ -603,6 +602,26 @@ private void updateBundleData() {
LoadManagerShared.fillNamespaceToBundlesMap(preallocatedBundleData.keySet(),
namespaceToBundleRange);
}
}
+
+ // Remove not active bundle from loadData
+ for (String bundle : bundleData.keySet()) {
+ if (!activeBundles.contains(bundle)) {
+ long notActiveTimes = notActiveBundleCounter
+ .computeIfAbsent(bundle, k -> new
AtomicLong()).incrementAndGet();
+
+ if (notActiveTimes > nonActiveBundleDeleteThreshold) {
Review Comment:
> Do we need to worry about other data inconsistencies, for example, between
this bundleData(and deleteBundleDataFromMetadataStore) vs other data structures?
For the time now. I think the bundleData is eventual consistency to create a
cluster wide bundle load view.
which means that the bundleData can be late but should be on the
metadataStore.
The undelete bundle data won't harm the other logic. most logic is just to
query the bundle data. If bundle is splited. the system won't to do other
operation for this bundle again.
And the other data-structure, I think the brokerData is update by the each
broker and update in time (which won't rely on the metric update) may be not a
problem for now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
