apache/pulsar · error · RestException

RestException(e)

Error message

RestException(e)

What it means

Same wrapping point as the ExecutionException path: if the getTopicIfExists future times out (exceeds config().getMetadataStoreOperationTimeoutSeconds()) or the waiting thread is interrupted, the broker throws RestException(e). Typically surfaces as HTTP 500 (server-side timeout) when topic lookup cannot complete in time.

Source

Thrown at pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/v2/NonPersistentTopics.java:707

                            .attr("isGlobal", isGlobal)
                            .log("Successfully remove entry filters");
                    asyncResponse.resume(Response.noContent().build());
                })
                .exceptionally(ex -> {
                    handleTopicPolicyException("removeEntryFilters", ex, asyncResponse);
                    return null;
                });
    }

    private Topic getTopicReference(TopicName topicName) {
        try {
            return pulsar().getBrokerService().getTopicIfExists(topicName.toString())
                    .get(config().getMetadataStoreOperationTimeoutSeconds(), TimeUnit.SECONDS)
                    .orElseThrow(() -> new RestException(Status.NOT_FOUND, "Topic not found"));
        } catch (ExecutionException e) {
            throw new RestException(e.getCause());
        } catch (InterruptedException | TimeoutException e) {
            throw new RestException(e);
        }
    }
}

View on GitHub (pinned to 820761864e)

Solutions

1. Increase broker metadataStoreOperationTimeoutSeconds if the store is legitimately slow
2. Check metadata store latency/health (ZooKeeper session issues, etcd slowness)
3. Retry the request; investigate broker logs for store timeouts

Example fix

// broker.conf
// before: metadataStoreOperationTimeoutSeconds=30
// after: metadataStoreOperationTimeoutSeconds=60

// pre-check broker/store responsiveness before issuing admin calls
admin.brokerStats().getTopics(); // cheap health probe

try { t = admin.topics().stats(topic); } catch (PulsarAdminException e) { if (isTimeout(e)) retryWithBackoff(); }

When it happens

Trigger: Calling an admin endpoint that calls getTopicReference while the metadata store is slow or overloaded; request takes longer than metadataStoreOperationTimeoutSeconds; thread interrupted during shutdown.

Common situations: Loaded brokers, slow/degraded metadata store, broker shutdown or restarts interrupting in-flight admin requests.

Related errors

• Time-out while checking authorization
• Concurrent modification
• e
• RestException(e)
• Failed to validate global cluster configuration : ns=%s ems

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