[Question] <title>Is it necessary to incorporate a local caching mechanism into the instance creation process?

[doveLin0818]

Question

Recently, I fixed an issue related to instance reuse; for more details, please refer to #2886. To quickly address the online bug, my solution was somewhat crude. Below is the modified code, which prevents instance reuse problems caused by IP switching.

However, if a user or organization needs to monitor multiple Kafka instances, the current logic becomes ineffective, as it continuously creates new Kafka instances, potentially leading to performance degradation. Similarly, the existing code for RocketMQ repeatedly creates instances without enabling reuse. If an enterprise monitors multiple instances and requires high real-time performance with short monitoring refresh intervals, the repeated creation of instances becomes a significant concern.

Therefore, I am considering whether it is necessary to introduce a local caching mechanism (such as using Caffeine). The key could be a combination of app+ip+host, and the value would be the corresponding instance. Additionally, setting a relatively small cache size to prevent memory overflow and implementing an LRU eviction policy—which aligns well with our monitoring scenarios—would effectively allow the reuse of created instance objects, and we can start by implementing this for the Kafka client first and subsequently enable a gradual rollout.

If the community agrees that this solution is viable, please assign it to me, and I am willing to implement it.

[tomsun28]

+1 connection local caching mechanism is already use in ssh db and soon. suggest we use ConnectionCommonCache in kafka client like others.
@zhangshenghang how about this?

[zhangshenghang]

+1 connection local caching mechanism is already use in ssh db 和 soon. suggest we use ConnectionCommonCache in kafka client like others. @zhangshenghang how about this?

This is a very good idea，@doveLin0818 Can you complete it? If you can, I will assign it to you.

@doveLin0818 You can refer to

hertzbeat/hertzbeat-collector/hertzbeat-collector-basic/src/main/java/org/apache/hertzbeat/collector/collect/ssh/SshCollectImpl.java

Line 74 in 4236c43

private final ConnectionCommonCache<CacheIdentifier, SshConnect> connectionCommonCache;

[doveLin0818]

+1 connection local caching mechanism is already use in ssh db 和 soon. suggest we use ConnectionCommonCache in kafka client like others. @zhangshenghang how about this?

This is a very good idea，@doveLin0818 Can you complete it? If you can, I will assign it to you.

@doveLin0818 You can refer to

hertzbeat/hertzbeat-collector/hertzbeat-collector-basic/src/main/java/org/apache/hertzbeat/collector/collect/ssh/SshCollectImpl.java

Line 74 in 4236c43

private final ConnectionCommonCache<CacheIdentifier, SshConnect> connectionCommonCache;

@zhangshenghang hi,please assign to me

[tomsun28]

BTW, another point. We can find that a new ConnectionCommonCache object is created in each collection class. Is this the best practice? Because each ConnectionCommonCache has a corresponding observation thread, etc., which takes up more resources.
How about use only one ConnectionCommonCache for these connection cache function.

[doveLin0818]

BTW, another point. We can find that a new ConnectionCommonCache object is created in each collection class. Is this the best practice? Because each ConnectionCommonCache has a corresponding observation thread, etc., which takes up more resources. How about use only one ConnectionCommonCache for these connection cache function.

Hi tom , I will try to optimize this.