-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[broker] Close topics that remain fenced forcefully #8561
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Add a doc-required label as the broker.config and standalone.config file are updated. |
| } else { | ||
| log.error("[{}] Topic remained fenced for {} seconds, so close it (pendingWriteOps: {})", topic, | ||
| timeout, pendingWriteOps.get()); | ||
| close(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to put close in the synchronized block?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed "synchronized" because there was no clear reason to make this method synchronized.
ef5b710 to
2032c99
Compare
|
@sijie Please help review this PR. |
|
/pulsarbot cherry-pick to branch-2.6 |
Motivation
The other day, we faced a problem where a topic remained fenced and unavailable. This topic remained unavailable until it was unloaded. The following is the broker log at that time.
We were maintaining the ZooKeeper servers, so I think this phenomenon was caused by the shutdown of some ZK servers. However, the causal relationship has not been clarified.
Modifications
As a workaround, close the topic if it remains fenced for a period of time. Reconnecting from the clients will instantiate a new
PersistentTopictopic and the topic will back to normal.