Skip to content

[fix][broker] Avoid load shedding and metadata writes from a former leader - #26253

Open
void-ptr974 wants to merge 2 commits into
apache:masterfrom
void-ptr974:fix/modular-load-manager-leader-guard
Open

[fix][broker] Avoid load shedding and metadata writes from a former leader#26253
void-ptr974 wants to merge 2 commits into
apache:masterfrom
void-ptr974:fix/modular-load-manager-leader-guard

Conversation

@void-ptr974

Copy link
Copy Markdown
Contributor

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

  • Recheck leadership before initiating bundle unloading.
  • Recheck leadership before writing bundle and broker load data to metadata.
  • Stop the remaining work when leadership has changed.

Verifying this change

This change added tests and can be verified as follows:

  • Added coverage for a follower skipping load shedding.
  • Added coverage for leadership changing after destination selection and before bundle unload.
  • Added coverage for leadership changing after aggregation and before metadata writes.
  • Ran ./gradlew :pulsar-broker:test -PtestGroups=broker -PexcludedTestGroups='' --tests org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImplTest --console=plain
  • Ran ./gradlew :pulsar-broker:checkstyleMain :pulsar-broker:checkstyleTest --console=plain

Does this pull request potentially affect one of the following parts:

  • Dependencies (add or upgrade a dependency)
  • The public API
  • The schema
  • The default values of configurations
  • The threading model
  • The binary protocol
  • The REST endpoints
  • The admin CLI options
  • The metrics
  • Anything that affects deployment

…eader

Recheck leader state before load-shedding side effects and metadata writes so a task that was already running stops after leadership changes.
@void-ptr974
void-ptr974 force-pushed the fix/modular-load-manager-leader-guard branch from ef5750a to d5e269e Compare July 28, 2026 01:58
pulsar.getAdminClient().namespaces()
.unloadNamespaceBundle(namespaceName, bundleRange, destBroker.get());
if (!isLeader()) {
return;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This return is inside nested forEach lambdas, so it only skips the current foreach.This could be optimized.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 68869bc. Replaced the nested lambdas with regular loops so leadership loss exits the load-shedding operation.

@Dream95

Dream95 commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Leader can still change between the isLeader() check and the actual unload, so this cannot fully prevent a former leader from triggering an unload.

@void-ptr974

Copy link
Copy Markdown
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants