A system topic can be unloaded, allowing it to be load balanced. If you filter the system topic, it may lead to uneven resource allocation.

In the master branch, topics/bundles in pulsar/system will be filter.
org.apache.pulsar.broker.loadbalance.LoadData#getBundleDataForLoadShedding

and actually we can achieve distributing bundles containing transaction_coordinator_assign evenly and avoiding unloading these bundles while shedding at the same time.

In our production clusters, we use AvgShedder described in #18186.

• When the cluster is initializing or the broker is restarted, bundles will be distributed randomly or based on hashing algorithm, which is similar to be a uniform distribution. So we can ensure that bundles containing transaction_coordinator_assign will be distributed evenly across brokers.
• When we need to do shedding, we will filter bundles containing transaction_coordinator_assign to avoid TC recovery.

In the master branch, topics/bundles in pulsar/system will be filter.

I think this logic was introduced by mistake by pr #15252

and actually we can achieve distributing bundles containing transaction_coordinator_assign evenly and avoiding unloading these bundles while shedding at the same time.

In our production clusters, we use AvgShedder described in #18186.

I will see the PIP later.

and I think the transaction_coordinator_assign can be shedding in any time, we could use a smoother strategy, but it doesn't prevent being shed

In the master branch, topics/bundles in pulsar/system will be filter.

I think this logic was introduced by mistake by pr #15252

Should i raise a PR to revert mistake in the master branch?

and I think the transaction_coordinator_assign can be shedding in any time, we could use a smoother strategy, but it doesn't prevent being shed

I think that load balancing strategy such as ThresholdShedder do not work well with transaction_coordinator_assign, which will do many meaningless bundles unloading. and the cost of TC recovery is pretty high that there are more than 20 minutes of unavailable time in our test.

Should i raise a PR to revert mistake in the master branch?

yes, I think we need a pr to revert this change

I think that load balancing strategy such as ThresholdShedder do not work well with transaction_coordinator_assign, > which will do many meaningless bundles unloading. and the cost of TC recovery is pretty high that there are more than 20 minutes of unavailable time in our test.

I think we need to find out why the Tc recover so slowly, Is it a logic error, or need to expand the TC?

if it is a logic error, we need to fix.

later I will think about how to optimize the recovery time of TC

The pr had no activity for 30 days, mark with Stale label.