[fix][broker] Avoid load shedding and metadata writes from a former leader - #26253
[fix][broker] Avoid load shedding and metadata writes from a former leader#26253void-ptr974 wants to merge 2 commits into
Conversation
…eader Recheck leader state before load-shedding side effects and metadata writes so a task that was already running stops after leadership changes.
ef5750a to
d5e269e
Compare
| pulsar.getAdminClient().namespaces() | ||
| .unloadNamespaceBundle(namespaceName, bundleRange, destBroker.get()); | ||
| if (!isLeader()) { | ||
| return; |
There was a problem hiding this comment.
This return is inside nested forEach lambdas, so it only skips the current foreach.This could be optimized.
There was a problem hiding this comment.
Fixed in 68869bc. Replaced the nested lambdas with regular loops so leadership loss exits the load-shedding operation.
|
Leader can still change between the isLeader() check and the actual unload, so this cannot fully prevent a former leader from triggering an unload. |
|
Thanks. This PR intentionally provides only a best-effort guard and does not address the narrow race between the leadership check and the unload itself. Providing a strong guarantee would require a broader fencing design, which is out of scope for this focused change. |
|
|
||
| @VisibleForTesting | ||
| boolean isLeader() { | ||
| return pulsar.getLeaderElectionService() != null && pulsar.getLeaderElectionService().isLeader(); |
There was a problem hiding this comment.
isLeader() only checks the local leader-election state. In LeaderElectionImpl.handleSessionNotification(), the Leading status is not invalidated on ConnectionLost or SessionLost—it is only revalidated after reconnection. Since SessionLost implies this broker’s ephemeral leader node may have already expired, isLeader() can continue returning true even after another broker has become leader.
This results in a significantly wider former‑leader window compared with the narrow check‑to‑unload race described later. The task‑level metadata‑availability check also does not protect against a session loss that occurs after the task has started, and the resource‑quota updator lacks such an entry check.
Could this guard incorrectly remain closed while lastMetadataSessionEvent.isConnected() is false, assuming proper volatile/atomic visibility for that field? Alternatively, leadership should be invalidated in LeaderElectionImpl when the session is lost.
| if (!isLeader()) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
updateBundleData() is not side-effect-free: before the leadership check runs, it can call deleteBundleDataFromMetadataStore() for inactive bundles. This method is also invoked from the metadata-notification-driven updateAll() path, and cleanupDeadBrokersData() includes a similar asynchronous deletion path for broker time‑average data.
Therefore, adding a leadership check after updateBundleData() does not prevent all metadata mutations by a former leader. An old leader could still delete data after a new leader has written it.
Could we modify updateBundleData() to perform only in‑memory aggregation and move deletions into the guarded write phase? Alternatively, could we apply the same leadership or session guard immediately before each deletion path? A regression test covering inactive‑bundle deletion during leadership loss would also be needed.
| if (!isLeader()) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
Returning here bypasses the broker's finalization and the method-level metrics update. This same problem occurs again with the leadership check immediately before unloading.
If a previous bundle for this broker has already been unloaded successfully, unloadBundleCount and recentlyUnloadedBundles are already updated and unloadBundleForBroker is set to true. Losing leadership before processing the next bundle then skips both unloadBrokerCount++ and updateBundleUnloadingMetrics(). This permanently undercounts the broker and leaves the published metrics stale.
Could we use a labeled break or a leadershipLost flag to exit the loops while still performing the finalization and metrics update?
3 participants
Motivation
Load-balancer tasks are started only while a broker is the leader. However, cancelling a scheduled task does not stop an invocation that is already in progress. If leadership changes during such an invocation, the former leader can still initiate bundle unloading or persist load-balancing metadata.
Modifications
Verifying this change
This change added tests and can be verified as follows:
./gradlew :pulsar-broker:test -PtestGroups=broker -PexcludedTestGroups='' --tests org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImplTest --console=plain./gradlew :pulsar-broker:checkstyleMain :pulsar-broker:checkstyleTest --console=plainDoes this pull request potentially affect one of the following parts: