[jira] [Created] (KAFKA-16417) When initializeResources throws an exception in TopicBasedRemoteLogMetadataManager.scala, initializationFailed needs to be set to true
zhaobo created KAFKA-16417: -- Summary: When initializeResources throws an exception in TopicBasedRemoteLogMetadataManager.scala, initializationFailed needs to be set to true Key: KAFKA-16417 URL: https://issues.apache.org/jira/browse/KAFKA-16417 Project: Kafka Issue Type: Bug Affects Versions: 3.2.0 Reporter: zhaobo -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KAFKA-13984) Fix TopicBasedRemoteLogMetadataManager#initializeResources should return immediately when the result of isPartitionsCountSameAsConfigured method is false
zhaobo created KAFKA-13984:
--
Summary: Fix
TopicBasedRemoteLogMetadataManager#initializeResources should return
immediately when the result of isPartitionsCountSameAsConfigured method is false
Key: KAFKA-13984
URL: https://issues.apache.org/jira/browse/KAFKA-13984
Project: Kafka
Issue Type: Improvement
Affects Versions: 3.2.0
Reporter: zhaobo
When executing
{code:java}
TopicBasedRemoteLogMetadataManager.initializeResources{code}
, if the result of isPartitionsCountSameAsConfigured method is false.
It means that the actual number of partitions in the internal topic
__remote_log_metadata is inconsistent with the number of partitions configured
in our configuration file
At this time, it is not very reasonable to continue the subsequent
initialization process.
We should raise an error to exit.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (KAFKA-13865) FIx ResponseSendTimeMs metric in RequestChannel.scala duplicate removed
zhaobo created KAFKA-13865: -- Summary: FIx ResponseSendTimeMs metric in RequestChannel.scala duplicate removed Key: KAFKA-13865 URL: https://issues.apache.org/jira/browse/KAFKA-13865 Project: Kafka Issue Type: Bug Reporter: zhaobo -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (KAFKA-13825) Fix some topic metric should remove when from leader to follower(deprecated)
[ https://issues.apache.org/jira/browse/KAFKA-13825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhaobo resolved KAFKA-13825. Resolution: Not A Problem > Fix some topic metric should remove when from leader to follower(deprecated) > > > Key: KAFKA-13825 > URL: https://issues.apache.org/jira/browse/KAFKA-13825 > Project: Kafka > Issue Type: Test >Affects Versions: 3.2.0 >Reporter: zhaobo >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (KAFKA-13825) Fix some topic metric should remove when from leader to follower
zhaobo created KAFKA-13825: -- Summary: Fix some topic metric should remove when from leader to follower Key: KAFKA-13825 URL: https://issues.apache.org/jira/browse/KAFKA-13825 Project: Kafka Issue Type: Bug Affects Versions: 3.2.0 Reporter: zhaobo -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (KAFKA-13778) Follower broker also always execute preferred read-replica selection
zhaobo created KAFKA-13778: -- Summary: Follower broker also always execute preferred read-replica selection Key: KAFKA-13778 URL: https://issues.apache.org/jira/browse/KAFKA-13778 Project: Kafka Issue Type: Bug Components: core Affects Versions: 3.2.0 Reporter: zhaobo Assignee: zhaobo The design purpose of the code is that only the leader broker can determine the preferred read-replica. But in fact, since the broker does not judge whether it is the leader or not, the follower will also execute the preferred read-replica selection. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (KAFKA-13767) consumer fetch request does not need to put to delayFetch queue when the preferred read replica not local
zhaobo created KAFKA-13767: -- Summary: consumer fetch request does not need to put to delayFetch queue when the preferred read replica not local Key: KAFKA-13767 URL: https://issues.apache.org/jira/browse/KAFKA-13767 Project: Kafka Issue Type: Improvement Components: core Affects Versions: 3.3.0 Reporter: zhaobo Fix For: 3.3.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (KAFKA-8543) Optimize Fetch thread allocation strategy to ensure full utilization of Fetch thread resources
zhaobo created KAFKA-8543: - Summary: Optimize Fetch thread allocation strategy to ensure full utilization of Fetch thread resources Key: KAFKA-8543 URL: https://issues.apache.org/jira/browse/KAFKA-8543 Project: Kafka Issue Type: Improvement Components: core Affects Versions: 2.2.0 Reporter: zhaobo The Follow TP on the Broker needs to fetch data from the Leader broker. The original fetch thread allocation strategy has two areas that can be optimized: （1）The configuration file has a parameter "num.consumer.fetchers" which limits the number of threads fetching data from a source broker. In fact, Fetch resources are not fully used, and only a part of the threads will be used with a high probability. When the traffic of the Leader TP increases, the fetch capability may be bottlenecked. （2）The number of TPs responsible for each Fetch thread may be uneven. Improve: We propose a polling allocation method to ensure that Fetch thread resources can be fully utilized. And the number of TPs responsible for each fetch thread is balanced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
