@RunLLM How does the broker configuration field

topicFencingTimeoutSeconds

work?

The

topicFencingTimeoutSeconds

broker configuration sets how long a fenced topic remains in the fenced state before being forcefully closed. If set to a positive value, after the specified number of seconds, the broker will close the topic if it remains fenced; if set to 0 or negative, the topic will not be closed automatically. This helps recover topics that are stuck in a fenced state, but setting it too low may risk data consistency issues if metadata is overwritten during the timeout window. According to ServiceConfiguration.java and PersistentTopic.java, this mechanism is implemented by scheduling a task to close the topic after the timeout. Would you like more detail on how this interacts with topic fencing and recovery? Sources: - ServiceConfiguration.java - PersistentTopic.java - GitHub Issue #20526 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@RunLLM What happens if the ledger does not exist anymore when the broker tries to close it?

If the ledger does not exist when the broker tries to close it, the broker will encounter a

NoSuchLedgerExistsOnMetadataServerException

from BookKeeper. This typically happens if another broker or process has already deleted the ledger. The broker logs a warning or error, and the close operation fails for that ledger, but Pulsar will proceed to create a new ledger and continue topic operations. This scenario is visible in logs and discussed in GitHub Issue #24901. Would you like more detail on the error handling or recovery process? Sources: - GitHub Issue #24901 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.