You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
+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?
+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.
+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.
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.
The text was updated successfully, but these errors were encountered: