apache/pulsar · warning · RestException

${loadManagerClass} does not support this operation

Error message

${loadManagerClass} does not support this operation

What it means

This HTTP 409 CONFLICT error is thrown by the broker-stats admin endpoint when the currently active LoadManager is not SimpleLoadManagerImpl. Only the legacy simple load manager exposes getResourceAvailabilityFor(namespace); other implementations (notably ModularLoadManagerImpl) do not implement this operation, so the admin API refuses rather than return meaningless data.

Source

Thrown at pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/impl/BrokerStatsBase.java:184

        validateSuperUserAccess();
        try {
            return (pulsar().getLoadManager().get()).generateLoadReport();
        } catch (Exception e) {
            log.error()
                    .exception(e)
                    .log("Failed to generate LoadReport for broker");
            throw new RestException(e);
        }
    }

    protected Map<Long, Collection<ResourceUnit>> internalBrokerResourceAvailability(NamespaceName namespace) {
        try {
            validateSuperUserAccess();
            LoadManager lm = pulsar().getLoadManager().get();
            if (lm instanceof SimpleLoadManagerImpl) {
                return ((SimpleLoadManagerImpl) lm).getResourceAvailabilityFor(namespace).asMap();
            } else {
                throw new RestException(Status.CONFLICT, lm.getClass().getName() + " does not support this operation");
            }
        } catch (Exception e) {
            log.error().exception(e).log("Unable to get Resource Availability");
            throw new RestException(e);
        }
    }
}

View on GitHub (pinned to 820761864e)

Solutions

1. Check the active load manager class (broker.conf loadManagerClassName, or GET /admin/v2/brokers/configuration) and switch to org.apache.pulsar.broker.loadbalance.impl.SimpleLoadManagerImpl if this endpoint is genuinely needed (requires broker restart and is not recommended).
2. Prefer the modern equivalent metrics instead of the endpoint: use GET /admin/v2/broker-stats/metrics or the load data endpoint /admin/v2/broker-stats/load-report, which work with ModularLoadManagerImpl.
3. Catch HTTP 409 on the client side and fall back to the supported load-data/metrics API for brokers running a non-simple load manager.

Example fix

// before (client assumes old endpoint works)
ResourceAvailability ra = admin.brokerStats().getResourceAvailability(ns);
// after
try {
    ra = admin.brokerStats().getResourceAvailability(ns);
} catch (PulsarAdminException.ConflictException e) {
    // fall back to load report / metrics supported by ModularLoadManagerImpl
    LoadReport lr = admin.brokerStats().getLoadReport();
}

// check active load manager before calling
String lmClass = admin.brokers().getDynamicConfiguration("loadManagerClassName");
if (lmClass != null && !lmClass.contains("SimpleLoadManagerImpl")) {
    // use load-report/metrics endpoints instead
}

try {
    return admin.brokerStats().getResourceAvailability(ns);
} catch (PulsarAdminException.ConflictException e) {
    return fallbackToLoadReport(admin);
}

When it happens

Trigger: Calling GET /admin/v2/broker-stats/available-resource-availability (internalBrokerResourceAvailability) as a superuser while the broker's loadManagerClassName is set to anything other than org.apache.pulsar.broker.loadbalance.impl.SimpleLoadManagerImpl, e.g. the default ModularLoadManagerImpl.

Common situations: Running a default/modern Pulsar configuration (ModularLoadManagerImpl is the default) and querying the legacy resource-availability endpoint; scripts or monitoring dashboards written against old Pulsar versions where SimpleLoadManagerImpl was the default; mixed-version clusters where a tool assumes the old load manager.

Related errors

• Topic is not partitioned topic
• This topic already exists
• Unauthorized to validateBothSuperuserAndBrokerOperation for
• Number of transaction coordinators should be more than the c
• Bookie 'group' parameters is missing

AI-assisted analysis of apache/pulsar@820761864e (2026-09-06). Data as JSON: /api/errors/5325bc7b8957d876. Report an issue: GitHub.