-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[fix][broker] Close protocol handlers channel #25111
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
base: master
Are you sure you want to change the base?
Conversation
BewareMyPower
left a comment
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.
Protocol handlers close before the ownership change in BrokerService#unloadNamespaceBundlesGracefully. Even if you close the channels before closing the protocol handler, the requests could still be sent to the broker and rejected. It's actually worse because no logs can be found at broker side.
lhotari
left a comment
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.
LGTM
BewareMyPower
left a comment
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.
Sorry I checked the logic again and found it's a bit different from broker's close logic,
The closing logic of broker is BrokerService#closeAsync:
- Unregister itself from metadata store and unload owned namespace bundles synchronously in
unloadNamespaceBundlesGracefully - Close built-in clients asynchronously
- Close event loops asynchronously
- After futures of 2 and 3 are done, close the listening channels
However, the closing logic of protocol handlers is a synchronous method ProtocolHandler#close.
Actually, before close is called, the protocol handler should not be treated as "closing". For example, the following implementation is legal:
@Override
public void close() {
try {
lookupClient.closeAsync().get();
} catch (InterruptedException | ExecutionException e) {
throw new RuntimeException(e);
}
}The lookupClient field might wrap a client that established a connection to itself for topic lookup. If the listening channel is closed before that, the closeAsync future might have a chance to keep reconnecting and failing, the get method might be blocked for long.
The root cause is that the closing phase of protocol handlers is not well-defined. We should let the downstream to determine when to close these channels.
A better solution is to pass the corresponding listening channel to each protocol handler via an interface method.
Motivation
During the shutdown process of Pulsar brokers, protocol handlers' channels are not properly closed, which allows new client requests to continue arriving even after the shutdown has been initiated. This can lead to:
The broker's
closeAsyncmethod properly handles closing all channels by callingchannel.close()on all channels inlistChannels. However, the same pattern is not applied to protocol handlers, leaving their channels open during the shutdown process.Modifications
closeProtocolHandlerChannels()method to properly close all protocol handler channels before callingprotocolHandler.close()closeAsyncVerifying this change
This change is already covered by existing tests, such as:
Does this pull request potentially affect one of the following parts:
If the box was checked, please highlight the changes
Documentation
[
docdoc-requireddoc-not-neededdoc-completeMatching PR in forked repository
gaozhangmin#14