-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[PIP-165] Auto release client useless connections #15516
Comments
@eolivelli @gaoran10 @gaozhangmin @315157973 @lhotari @michaeljmarshall I have sent an email, could you take a look. |
@eolivelli @gaoran10 @gaozhangmin @315157973 @lhotari @michaeljmarshall I have start a vote and already send email, could you take a look. Discuss Link: https://lists.apache.org/thread/t6h98qs2coc56z06tw38hdlljl67ft4n |
Left a comment in discuss email list. |
Maybe the config |
Good idea. I changed it. Thanks @gaoran10 |
Left a comment in discuss email list:) |
@eolivelli @315157973 Can you give a vote for this proposal, Thanks. https://lists.apache.org/thread/qfg9jfocpsc0tzy45ozgoothw1jpxk5g |
The issue had no activity for 30 days, mark with Stale label. |
### Motivation The go implementation of PIP-165:apache/pulsar#15516 ### Modifications * Add new configuration `ConnectionMaxIdleTime` to `ClientOptions` * Add a goroutine to `ConnectionPool` to period check and release idle connections.
Motivation
Currently, the Pulsar client keeps the connection even if no producers or consumers use this connection.
If a client produces messages to topic A and we have 3 brokers 1, 2, 3. Due to the bundle unloading(load manager)
topic ownership will change from A to B and finally to C. For now, the client-side will keep 3 connections to all 3 brokers.
We can optimize this part to reduce the broker side connections, the client should close the unused connections.
So a mechanism needs to be added to release unwanted connections.
Why are there idle connections?
1.When configuration
maxConnectionsPerHosts
is not set to 0, the connection is not closed at all.The design is to hold a fixed number of connections per Host, avoiding frequent closing and creation.
pulsar/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ConnectionPool.java
Lines 325 to 335 in 7234911
2-1. When clients receive
command-close
, will reconnect immediately.It's designed to make it possible to reconnect, rebalance, and unload.
pulsar/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ConnectionHandler.java
Lines 122 to 141 in 7234911
2-2. The broker will close client connections before writing ownership info to the ZK. Then clients will get deprecated broker address when it tries lookup.
pulsar/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentTopic.java
Lines 1282 to 1293 in 7234911
Goal
Automatically release connections that are no longer used.
Pulsar client
Contains connections used by consumers, Producers, and Transactions.
Pulsar proxy
The connection between proxy and broker has two parts: For lookup commands; For consumers, producers commands and other commands.
The connection "For consumers, producers commands and other commands" is managed by DirectProxyHandler, which holds the connection until the client is closed, so it does not affect of producers or consumers, These connections do not require additional closing.
The connection "For lookup commands": When the proxy is configured
metadataStoreUrl
, the Lookup Command will select the registered broker by rotation training and create a connection. If we do not optimize the broker load balancing algorithm, all connections are considered useful connections.When the cluster is large, holds so many connections becomes redundant. Later, I will try to put forward other proposals to improve this phenomenon, so this proposal does not involve proxy connection release.
Approach
Periodically check for idle connections and close them.
Changes
API changes
ClientCnx added an idle check method to mark idle time.
Configuration changes
We can set the check frequency and release rule for idle connections at
ClientConfigurationData
.Implementation
If no consumer, producer, or transaction uses the current connection, release it.
The text was updated successfully, but these errors were encountered: