[jira] [Updated] (KAFKA-16710) Continuously `makeFollower` may cause the replica fetcher thread to encounter an offset mismatch exception when `processPartitionData`

[ https://issues.apache.org/jira/browse/KAFKA-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-16710: --- Attachment: 企业微信截图_230257fe-1c11-4e77-93b3-b8b8edce2ba3.png

[jira] [Updated] (KAFKA-16710) Continuously `makeFollower` may cause the replica fetcher thread to encounter an offset mismatch exception when `processPartitionData`

[ https://issues.apache.org/jira/browse/KAFKA-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-16710: --- Description: The scenario where this case occurs is during a reassignment of a partition: 110879, 110880

[jira] [Updated] (KAFKA-16710) Continuously `makeFollower` may cause the replica fetcher thread to encounter an offset mismatch exception when `processPartitionData`

[ https://issues.apache.org/jira/browse/KAFKA-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-16710: --- Description: The scenario where this case occurs is during a reassignment of a partition: 110879, 110880

[jira] [Created] (KAFKA-16710) Continuously `makeFollower` may cause the replica fetcher thread to encounter an offset mismatch exception when `processPartitionData`

hudeqi created KAFKA-16710: -- Summary: Continuously `makeFollower` may cause the replica fetcher thread to encounter an offset mismatch exception when `processPartitionData` Key: KAFKA-16710 URL:

[jira] [Updated] (KAFKA-16543) There may be ambiguous deletions in the `cleanupGroupMetadata` when the generation of the group is less than or equal to 0

[ https://issues.apache.org/jira/browse/KAFKA-16543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-16543: --- Description: In the `cleanupGroupMetadata` method, tombstone messages is written to delete the group's

[jira] [Created] (KAFKA-16543) There may be ambiguous deletions in the `cleanupGroupMetadata` when the generation of the group is less than or equal to 0

hudeqi created KAFKA-16543: -- Summary: There may be ambiguous deletions in the `cleanupGroupMetadata` when the generation of the group is less than or equal to 0 Key: KAFKA-16543 URL:

[jira] [Assigned] (KAFKA-15764) Missing tests for transactions

[ https://issues.apache.org/jira/browse/KAFKA-15764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-15764: -- Assignee: hudeqi > Missing tests for transactions > -- > >

[jira] [Commented] (KAFKA-15764) Missing tests for transactions

[ https://issues.apache.org/jira/browse/KAFKA-15764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781288#comment-17781288 ] hudeqi commented on KAFKA-15764: I can pick it up. > Missing tests for transactions >

[jira] [Commented] (KAFKA-15313) Delete remote log segments partition asynchronously when a partition is deleted.

[ https://issues.apache.org/jira/browse/KAFKA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781257#comment-17781257 ] hudeqi commented on KAFKA-15313: Hi, [~abhijeetkumar]   Are you still following this issue? If you don't

[jira] [Assigned] (KAFKA-15331) Handle remote log enabled topic deletion when leader is not available

[ https://issues.apache.org/jira/browse/KAFKA-15331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-15331: -- Assignee: hudeqi > Handle remote log enabled topic deletion when leader is not available >

[jira] [Commented] (KAFKA-15432) RLM Stop partitions should not be invoked for non-tiered storage topics

[ https://issues.apache.org/jira/browse/KAFKA-15432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780818#comment-17780818 ] hudeqi commented on KAFKA-15432: I will take it over if no anyone is not following this. Thanks

[jira] [Assigned] (KAFKA-15432) RLM Stop partitions should not be invoked for non-tiered storage topics

[ https://issues.apache.org/jira/browse/KAFKA-15432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-15432: -- Assignee: hudeqi > RLM Stop partitions should not be invoked for non-tiered storage topics >

[jira] [Commented] (KAFKA-15300) Include remotelog size in complete log size and also add local log size and remote log size separately in kafka-log-dirs tool.

[ https://issues.apache.org/jira/browse/KAFKA-15300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780816#comment-17780816 ] hudeqi commented on KAFKA-15300: Can I take over this issue? [~satish.duggana] Can you describe this

[jira] [Commented] (KAFKA-15376) Explore options of removing data earlier to the current leader's leader epoch lineage for topics enabled with tiered storage.

[ https://issues.apache.org/jira/browse/KAFKA-15376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780815#comment-17780815 ] hudeqi commented on KAFKA-15376: Can I take over this issue? [~satish.duggana]  > Explore options of

[jira] [Commented] (KAFKA-15038) Use topic id/name mapping from the Metadata cache in the RemoteLogManager

[ https://issues.apache.org/jira/browse/KAFKA-15038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780814#comment-17780814 ] hudeqi commented on KAFKA-15038: Hi, [~owen-leung]  Are you still following this issue? If you don't

[jira] [Commented] (KAFKA-15331) Handle remote log enabled topic deletion when leader is not available

[ https://issues.apache.org/jira/browse/KAFKA-15331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780812#comment-17780812 ] hudeqi commented on KAFKA-15331: Hi, [~_gargantua_]  Are you still following this issue? If you don't

[jira] [Commented] (KAFKA-12641) Clear RemoteLogLeaderEpochState entry when it become empty.

[ https://issues.apache.org/jira/browse/KAFKA-12641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780809#comment-17780809 ] hudeqi commented on KAFKA-12641: Hi, [~abhijeetkumar] Are you still following this issue? If you don't

[jira] [Commented] (KAFKA-13355) Shutdown broker eventually when unrecoverable exceptions like IOException encountered in RLMM.

[ https://issues.apache.org/jira/browse/KAFKA-13355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780810#comment-17780810 ] hudeqi commented on KAFKA-13355: Hi, [~abhijeetkumar]  Are you still following this issue? If you don't

[jira] [Assigned] (KAFKA-15671) Flaky test RemoteIndexCacheTest.testClearCacheAndIndexFilesWhenResizeCache

[ https://issues.apache.org/jira/browse/KAFKA-15671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-15671: -- Assignee: hudeqi > Flaky test RemoteIndexCacheTest.testClearCacheAndIndexFilesWhenResizeCache >

[jira] [Commented] (KAFKA-15671) Flaky test RemoteIndexCacheTest.testClearCacheAndIndexFilesWhenResizeCache

[ https://issues.apache.org/jira/browse/KAFKA-15671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779022#comment-17779022 ] hudeqi commented on KAFKA-15671: Hi, [~brian030128] , I saw that this issue needs a quick fix. I know a

[jira] [Updated] (KAFKA-15396) Add a metric indicating the version of the current running kafka server

[ https://issues.apache.org/jira/browse/KAFKA-15396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15396: --- Affects Version/s: 3.6.0 (was: 3.5.1) > Add a metric indicating the version of

[jira] [Updated] (KAFKA-15607) Possible NPE is thrown in MirrorCheckpointTask

[ https://issues.apache.org/jira/browse/KAFKA-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15607: --- Attachment: SeaTalk_IMG_20231019_174340.png > Possible NPE is thrown in MirrorCheckpointTask >

[jira] [Updated] (KAFKA-15607) Possible NPE is thrown in MirrorCheckpointTask

[ https://issues.apache.org/jira/browse/KAFKA-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15607: --- Affects Version/s: 3.7.0 > Possible NPE is thrown in MirrorCheckpointTask >

[jira] [Updated] (KAFKA-15607) Possible NPE is thrown in MirrorCheckpointTask

[ https://issues.apache.org/jira/browse/KAFKA-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15607: --- Affects Version/s: 3.6.0 (was: 3.7.0) > Possible NPE is thrown in

[jira] [Updated] (KAFKA-15607) Possible NPE is thrown in MirrorCheckpointTask

[ https://issues.apache.org/jira/browse/KAFKA-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15607: --- Attachment: SeaTalk_IMG_20231019_172945.png > Possible NPE is thrown in MirrorCheckpointTask >

[jira] [Updated] (KAFKA-15607) Possible NPE is thrown in MirrorCheckpointTask

[ https://issues.apache.org/jira/browse/KAFKA-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15607: --- Description: In the `syncGroupOffset` method, if `targetConsumerOffset.get(topicPartition)` gets null,

[jira] [Created] (KAFKA-15607) Possible NPE is thrown in MirrorCheckpointTask

hudeqi created KAFKA-15607: -- Summary: Possible NPE is thrown in MirrorCheckpointTask Key: KAFKA-15607 URL: https://issues.apache.org/jira/browse/KAFKA-15607 Project: Kafka Issue Type: Bug

[jira] [Commented] (KAFKA-15535) Add documentation of "remote.log.index.file.cache.total.size.bytes" configuration property.

[ https://issues.apache.org/jira/browse/KAFKA-15535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772948#comment-17772948 ] hudeqi commented on KAFKA-15535: Is this marked as resolved? The doc of

[jira] [Updated] (KAFKA-15536) dynamically resize remoteIndexCache

[ https://issues.apache.org/jira/browse/KAFKA-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15536: --- Affects Version/s: 3.7.0 (was: 3.6.0) > dynamically resize remoteIndexCache >

[jira] [Assigned] (KAFKA-15535) Add documentation of "remote.log.index.file.cache.total.size.bytes" configuration property.

[ https://issues.apache.org/jira/browse/KAFKA-15535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-15535: -- Assignee: hudeqi > Add documentation of "remote.log.index.file.cache.total.size.bytes" >

[jira] [Reopened] (KAFKA-15397) Deserializing produce requests may cause memory leaks when exceptions occur

[ https://issues.apache.org/jira/browse/KAFKA-15397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reopened KAFKA-15397: > Deserializing produce requests may cause memory leaks when exceptions occur >

[jira] [Commented] (KAFKA-14912) Introduce a configuration for remote index cache size, preferably a dynamic config.

[ https://issues.apache.org/jira/browse/KAFKA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763002#comment-17763002 ] hudeqi commented on KAFKA-14912: Thanks, [~showuon] . The PR corresponding to this issue is currently

[jira] [Commented] (KAFKA-15397) Deserializing produce requests may cause memory leaks when exceptions occur

[ https://issues.apache.org/jira/browse/KAFKA-15397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761165#comment-17761165 ] hudeqi commented on KAFKA-15397: yes, the analysis in the attachment is based on the heap dump. >

[jira] [Commented] (KAFKA-15397) Deserializing produce requests may cause memory leaks when exceptions occur

[ https://issues.apache.org/jira/browse/KAFKA-15397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761149#comment-17761149 ] hudeqi commented on KAFKA-15397: I applied the fix of this PR online and saw that the frequency of full

[jira] [Commented] (KAFKA-15397) Deserializing produce requests may cause memory leaks when exceptions occur

[ https://issues.apache.org/jira/browse/KAFKA-15397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760223#comment-17760223 ] hudeqi commented on KAFKA-15397: [~showuon]

[jira] [Resolved] (KAFKA-15397) Deserializing produce requests may cause memory leaks when exceptions occur

[ https://issues.apache.org/jira/browse/KAFKA-15397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi resolved KAFKA-15397. Resolution: Resolved > Deserializing produce requests may cause memory leaks when exceptions occur >

[jira] [Commented] (KAFKA-15397) Deserializing produce requests may cause memory leaks when exceptions occur

[ https://issues.apache.org/jira/browse/KAFKA-15397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760204#comment-17760204 ] hudeqi commented on KAFKA-15397: It seems that this commit: ”MINOR: Add more validation during KRPC

[jira] [Updated] (KAFKA-15397) Deserializing produce requests may cause memory leaks when exceptions occur

[ https://issues.apache.org/jira/browse/KAFKA-15397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15397: --- Affects Version/s: 2.8.1 (was: 3.5.1) > Deserializing produce requests may cause

[jira] [Commented] (KAFKA-15396) Add a metric indicating the version of the current running kafka server

[ https://issues.apache.org/jira/browse/KAFKA-15396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759514#comment-17759514 ] hudeqi commented on KAFKA-15396: Hi, [~divijvaidya] [~jolshan] I have added kip-972 link in this jira,

[jira] [Commented] (KAFKA-15396) Add a metric indicating the version of the current running kafka server

[ https://issues.apache.org/jira/browse/KAFKA-15396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759492#comment-17759492 ] hudeqi commented on KAFKA-15396: thanks, I will submit here. > Add a metric indicating the version of

[jira] [Updated] (KAFKA-15397) Deserializing produce requests may cause memory leaks when exceptions occur

[ https://issues.apache.org/jira/browse/KAFKA-15397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15397: --- Attachment: SeaTalk_IMG_1692796505.png SeaTalk_IMG_1692796533.png

[jira] [Updated] (KAFKA-15397) Deserializing produce requests may cause memory leaks when exceptions occur

[ https://issues.apache.org/jira/browse/KAFKA-15397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15397: --- Description: When the client sends a produce request in an abnormal way and the server accepts it for

[jira] [Created] (KAFKA-15397) Deserializing produce requests may cause memory leaks when exceptions occur

hudeqi created KAFKA-15397: -- Summary: Deserializing produce requests may cause memory leaks when exceptions occur Key: KAFKA-15397 URL: https://issues.apache.org/jira/browse/KAFKA-15397 Project: Kafka

[jira] [Created] (KAFKA-15396) Add a metric indicating the version of the current running kafka server

hudeqi created KAFKA-15396: -- Summary: Add a metric indicating the version of the current running kafka server Key: KAFKA-15396 URL: https://issues.apache.org/jira/browse/KAFKA-15396 Project: Kafka

[jira] [Commented] (KAFKA-14912) Introduce a configuration for remote index cache size, preferably a dynamic config.

[ https://issues.apache.org/jira/browse/KAFKA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756895#comment-17756895 ] hudeqi commented on KAFKA-14912: But how to measure and get the size of the entry? [~divijvaidya]  >

[jira] [Commented] (KAFKA-15172) Allow exact mirroring of ACLs between clusters

[ https://issues.apache.org/jira/browse/KAFKA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754541#comment-17754541 ] hudeqi commented on KAFKA-15172: This KIP is seldom discussed, what should I do next? [~mimaison]  >

[jira] [Commented] (KAFKA-14912) Introduce a configuration for remote index cache size, preferably a dynamic config.

[ https://issues.apache.org/jira/browse/KAFKA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754089#comment-17754089 ] hudeqi commented on KAFKA-14912: Hi, [~divijvaidya] Caffeine does support “a max size by bytes”. If I

[jira] [Commented] (KAFKA-15172) Allow exact mirroring of ACLs between clusters

[ https://issues.apache.org/jira/browse/KAFKA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17752398#comment-17752398 ] hudeqi commented on KAFKA-15172: Hi, I have initiated a kip discussion:

[jira] [Assigned] (KAFKA-14912) Introduce a configuration for remote index cache size, preferably a dynamic config.

[ https://issues.apache.org/jira/browse/KAFKA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-14912: -- Assignee: hudeqi > Introduce a configuration for remote index cache size, preferably a dynamic >

[jira] [Commented] (KAFKA-14912) Introduce a configuration for remote index cache size, preferably a dynamic config.

[ https://issues.apache.org/jira/browse/KAFKA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17752229#comment-17752229 ] hudeqi commented on KAFKA-14912: ok, i'll take a look in the last few days, thx > Introduce a

[jira] [Updated] (KAFKA-15172) Allow exact mirroring of ACLs between clusters

[ https://issues.apache.org/jira/browse/KAFKA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15172: --- Labels: kip-965 (was: needs-kip) > Allow exact mirroring of ACLs between clusters >

[jira] [Updated] (KAFKA-15129) Clean up all metrics that were forgotten to be closed

[ https://issues.apache.org/jira/browse/KAFKA-15129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15129: --- Description: In the current kafka code, there are still many module metrics that are forgotten to be

[jira] [Commented] (KAFKA-15194) Rename local tiered storage segment with offset as prefix for easy navigation

[ https://issues.apache.org/jira/browse/KAFKA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744148#comment-17744148 ] hudeqi commented on KAFKA-15194: thanks [~divijvaidya] I still don't know much about "tiered storage"

[jira] [Assigned] (KAFKA-14467) Add a test to validate the replica state after processing the OFFSET_MOVED_TO_TIERED_STORAGE error, especially for the transactional state

[ https://issues.apache.org/jira/browse/KAFKA-14467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-14467: -- Assignee: hudeqi > Add a test to validate the replica state after processing the >

[jira] [Commented] (KAFKA-14467) Add a test to validate the replica state after processing the OFFSET_MOVED_TO_TIERED_STORAGE error, especially for the transactional state

[ https://issues.apache.org/jira/browse/KAFKA-14467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744147#comment-17744147 ] hudeqi commented on KAFKA-14467: Thanks, I took over first, I'll look at this later. > Add a test to

[jira] [Commented] (KAFKA-14467) Add a test to validate the replica state after processing the OFFSET_MOVED_TO_TIERED_STORAGE error, especially for the transactional state

[ https://issues.apache.org/jira/browse/KAFKA-14467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744087#comment-17744087 ] hudeqi commented on KAFKA-14467: Isn't this issue [~showuon]  in charge ？ > Add a test to validate the

[jira] [Commented] (KAFKA-15172) Allow exact mirroring of ACLs between clusters

[ https://issues.apache.org/jira/browse/KAFKA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742994#comment-17742994 ] hudeqi commented on KAFKA-15172: Hi,[~mimaison] [~ChrisEgerton]  I am currently doing the work of using

[jira] [Assigned] (KAFKA-15172) Allow exact mirroring of ACLs between clusters

[ https://issues.apache.org/jira/browse/KAFKA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-15172: -- Assignee: hudeqi > Allow exact mirroring of ACLs between clusters >

[jira] [Commented] (KAFKA-14912) Introduce a configuration for remote index cache size, preferably a dynamic config.

[ https://issues.apache.org/jira/browse/KAFKA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742624#comment-17742624 ] hudeqi commented on KAFKA-14912: Hi [~divijvaidya] [~manyanda] I am also interested, if you are busy

[jira] [Resolved] (KAFKA-15139) Optimize the performance of `Set.removeAll(List)` in `MirrorCheckpointConnector`

[ https://issues.apache.org/jira/browse/KAFKA-15139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi resolved KAFKA-15139. Resolution: Fixed > Optimize the performance of `Set.removeAll(List)` in > `MirrorCheckpointConnector` >

[jira] [Updated] (KAFKA-15139) Optimize the performance of `Set.removeAll(List)` in `MirrorCheckpointConnector`

[ https://issues.apache.org/jira/browse/KAFKA-15139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15139: --- Description: This is the hint of `removeAll` method in `Set`: _This implementation determines which is the

[jira] [Updated] (KAFKA-15139) Optimize the performance of `Set.removeAll(List)` in `MirrorCheckpointConnector`

[ https://issues.apache.org/jira/browse/KAFKA-15139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15139: --- Description: This is the hint of `removeAll` method in `Set`: _This implementation determines which is the

[jira] [Created] (KAFKA-15139) Optimize the performance of `Set.removeAll(List)` in `MirrorCheckpointConnector`

hudeqi created KAFKA-15139: -- Summary: Optimize the performance of `Set.removeAll(List)` in `MirrorCheckpointConnector` Key: KAFKA-15139 URL: https://issues.apache.org/jira/browse/KAFKA-15139 Project: Kafka

[jira] [Updated] (KAFKA-15134) Enrich the prompt reason in CommitFailedException

[ https://issues.apache.org/jira/browse/KAFKA-15134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15134: --- Attachment: WechatIMG31.jpeg > Enrich the prompt reason in CommitFailedException >

[jira] [Updated] (KAFKA-15134) Enrich the prompt reason in CommitFailedException

[ https://issues.apache.org/jira/browse/KAFKA-15134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15134: --- Description: Firstly, let me post the exception log of the client running:

[jira] [Created] (KAFKA-15134) Enrich the prompt reason in CommitFailedException

hudeqi created KAFKA-15134: -- Summary: Enrich the prompt reason in CommitFailedException Key: KAFKA-15134 URL: https://issues.apache.org/jira/browse/KAFKA-15134 Project: Kafka Issue Type:

[jira] [Updated] (KAFKA-15129) Clean up all metrics that were forgotten to be closed

[ https://issues.apache.org/jira/browse/KAFKA-15129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15129: --- Description: In the current kafka code, there are still many module metrics that are forgotten to be

[jira] [Created] (KAFKA-15129) Clean up all metrics that were forgotten to be closed

hudeqi created KAFKA-15129: -- Summary: Clean up all metrics that were forgotten to be closed Key: KAFKA-15129 URL: https://issues.apache.org/jira/browse/KAFKA-15129 Project: Kafka Issue Type:

[jira] [Updated] (KAFKA-15086) The unreasonable segment size setting of the internal topics in MM2 may cause the worker startup time to be too long

[ https://issues.apache.org/jira/browse/KAFKA-15086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15086: --- Labels: kip-943 (was: ) > The unreasonable segment size setting of the internal topics in MM2 may cause >

[jira] [Updated] (KAFKA-15119) Support incremental synchronization of topicAcl in MirrorSourceConnector

[ https://issues.apache.org/jira/browse/KAFKA-15119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15119: --- Description: In the “syncTopicAcls” thread of MirrorSourceConnector, full amount of "TopicAclBindings"

[jira] [Created] (KAFKA-15119) Support incremental synchronization of topicAcl in MirrorSourceConnector

hudeqi created KAFKA-15119: -- Summary: Support incremental synchronization of topicAcl in MirrorSourceConnector Key: KAFKA-15119 URL: https://issues.apache.org/jira/browse/KAFKA-15119 Project: Kafka

[jira] [Commented] (KAFKA-15110) Wrong version may be run, which will cause to fail to run when there are multiple version jars under core/build/libs

[ https://issues.apache.org/jira/browse/KAFKA-15110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735644#comment-17735644 ] hudeqi commented on KAFKA-15110: Leave an exception log so that others can find this problem：  

[jira] [Updated] (KAFKA-15110) Wrong version may be run, which will cause to fail to run when there are multiple version jars under core/build/libs

[ https://issues.apache.org/jira/browse/KAFKA-15110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15110: --- Attachment: WechatIMG29.jpeg > Wrong version may be run, which will cause to fail to run when there are >

[jira] [Updated] (KAFKA-15110) Wrong version may be run, which will cause to fail to run when there are multiple version jars under core/build/libs

[ https://issues.apache.org/jira/browse/KAFKA-15110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15110: --- Attachment: WechatIMG28.jpeg > Wrong version may be run, which will cause to fail to run when there are >

[jira] [Updated] (KAFKA-15110) Wrong version may be run, which will cause to fail to run when there are multiple version jars under core/build/libs

[ https://issues.apache.org/jira/browse/KAFKA-15110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15110: --- Description: For example, when I build a jar through './gradlew jar' under a 3.5.0 branch, and then switch

[jira] [Updated] (KAFKA-15110) Wrong version may be run, which will cause to fail to run when there are multiple version jars under core/build/libs

[ https://issues.apache.org/jira/browse/KAFKA-15110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15110: --- Summary: Wrong version may be run, which will cause to fail to run when there are multiple version jars

[jira] [Created] (KAFKA-15110) Wrong version may be run, which will cause it to fail to run when there are multiple version jars under core/build/libs

hudeqi created KAFKA-15110: -- Summary: Wrong version may be run, which will cause it to fail to run when there are multiple version jars under core/build/libs Key: KAFKA-15110 URL:

[jira] [Updated] (KAFKA-15086) The unreasonable segment size setting of the internal topics in MM2 may cause the worker startup time to be too long

[ https://issues.apache.org/jira/browse/KAFKA-15086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15086: --- Description: As the config 'segment.bytes' for topics related MM2(such as offset.storage.topic, 

[jira] [Updated] (KAFKA-15086) The unreasonable segment size setting of the internal topics in MM2 may cause the worker startup time to be too long

[ https://issues.apache.org/jira/browse/KAFKA-15086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15086: --- Attachment: WechatIMG366.jpeg > The unreasonable segment size setting of the internal topics in MM2 may

[jira] [Updated] (KAFKA-15086) The unreasonable segment size setting of the internal topics in MM2 may cause the worker startup time to be too long

[ https://issues.apache.org/jira/browse/KAFKA-15086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15086: --- Attachment: WechatIMG365.jpeg > The unreasonable segment size setting of the internal topics in MM2 may

[jira] [Updated] (KAFKA-15086) The unreasonable segment size setting of the internal topics in MM2 may cause the worker startup time to be too long

[ https://issues.apache.org/jira/browse/KAFKA-15086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15086: --- Attachment: WechatIMG364.jpeg > The unreasonable segment size setting of the internal topics in MM2 may

[jira] [Created] (KAFKA-15086) The unreasonable segment size setting of the internal topics in MM2 may cause the worker startup time to be too long

hudeqi created KAFKA-15086: -- Summary: The unreasonable segment size setting of the internal topics in MM2 may cause the worker startup time to be too long Key: KAFKA-15086 URL:

[jira] [Updated] (KAFKA-9613) CorruptRecordException: Found record size 0 smaller than minimum record overhead

[ https://issues.apache.org/jira/browse/KAFKA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-9613: -- Affects Version/s: 2.6.2 > CorruptRecordException: Found record size 0 smaller than minimum record > overhead

[jira] [Updated] (KAFKA-9613) CorruptRecordException: Found record size 0 smaller than minimum record overhead

[ https://issues.apache.org/jira/browse/KAFKA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-9613: -- Component/s: core > CorruptRecordException: Found record size 0 smaller than minimum record > overhead >

[jira] [Assigned] (KAFKA-9613) CorruptRecordException: Found record size 0 smaller than minimum record overhead

[ https://issues.apache.org/jira/browse/KAFKA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-9613: - Assignee: hudeqi > CorruptRecordException: Found record size 0 smaller than minimum record > overhead

[jira] [Assigned] (KAFKA-6668) Broker crashes on restart ,got a CorruptRecordException: Record size is smaller than minimum record overhead(14)

[ https://issues.apache.org/jira/browse/KAFKA-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-6668: - Assignee: hudeqi > Broker crashes on restart ,got a CorruptRecordException: Record size is > smaller

[jira] [Commented] (KAFKA-9613) CorruptRecordException: Found record size 0 smaller than minimum record overhead

[ https://issues.apache.org/jira/browse/KAFKA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731863#comment-17731863 ] hudeqi commented on KAFKA-9613: --- I have also encountered this problem online. Based on the time point and

[jira] [Commented] (KAFKA-6668) Broker crashes on restart ,got a CorruptRecordException: Record size is smaller than minimum record overhead(14)

[ https://issues.apache.org/jira/browse/KAFKA-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731862#comment-17731862 ] hudeqi commented on KAFKA-6668: --- I have also encountered this issue online. Based on the time point and

[jira] [Commented] (KAFKA-15068) Incorrect replication Latency may be calculated when the timestamp of the record is of type CREATE_TIME

[ https://issues.apache.org/jira/browse/KAFKA-15068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730100#comment-17730100 ] hudeqi commented on KAFKA-15068: @[~ChrisEgerton] Hello, if you have time, please take a look at this

[jira] [Updated] (KAFKA-15068) Incorrect replication Latency may be calculated when the timestamp of the record is of type CREATE_TIME

[ https://issues.apache.org/jira/browse/KAFKA-15068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-15068: --- Description: When MM2 is used to replicate topics between Kafka clusters, if the timestamp of the record

[jira] [Created] (KAFKA-15068) Incorrect replication Latency may be calculated when the timestamp of the record is of type CREATE_TIME

hudeqi created KAFKA-15068: -- Summary: Incorrect replication Latency may be calculated when the timestamp of the record is of type CREATE_TIME Key: KAFKA-15068 URL: https://issues.apache.org/jira/browse/KAFKA-15068

[jira] [Commented] (KAFKA-14979) Incorrect lag was calculated when markPartitionsForTruncation in ReplicaAlterLogDirsThread

[ https://issues.apache.org/jira/browse/KAFKA-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721163#comment-17721163 ] hudeqi commented on KAFKA-14979: [GitHub Pull Request #13692|https://github.com/apache/kafka/pull/13692]

[jira] [Updated] (KAFKA-14979) Incorrect lag was calculated when markPartitionsForTruncation in ReplicaAlterLogDirsThread

[ https://issues.apache.org/jira/browse/KAFKA-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-14979: --- Description: When the partitions of ReplicaFetcherThread finished truncating, the

[jira] [Updated] (KAFKA-14979) Incorrect lag was calculated when markPartitionsForTruncation in ReplicaAlterLogDirsThread

[ https://issues.apache.org/jira/browse/KAFKA-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-14979: --- Description: When the partitions of ReplicaFetcherThread finished truncating, the

[jira] [Assigned] (KAFKA-14979) Incorrect lag was calculated when markPartitionsForTruncation in ReplicaAlterLogDirsThread

[ https://issues.apache.org/jira/browse/KAFKA-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reassigned KAFKA-14979: -- Assignee: hudeqi > Incorrect lag was calculated when markPartitionsForTruncation in >

[jira] [Created] (KAFKA-14979) Incorrect lag was calculated when markPartitionsForTruncation in ReplicaAlterLogDirsThread

hudeqi created KAFKA-14979: -- Summary: Incorrect lag was calculated when markPartitionsForTruncation in ReplicaAlterLogDirsThread Key: KAFKA-14979 URL: https://issues.apache.org/jira/browse/KAFKA-14979

[jira] [Updated] (KAFKA-14907) Add the traffic metric of the partition dimension in BrokerTopicStats

[ https://issues.apache.org/jira/browse/KAFKA-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-14907: --- Labels: KIP-922 (was: ) > Add the traffic metric of the partition dimension in BrokerTopicStats >

[jira] [Updated] (KAFKA-14907) Add the traffic metric of the partition dimension in BrokerTopicStats

[ https://issues.apache.org/jira/browse/KAFKA-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi updated KAFKA-14907: --- Description: {color:#172b4d}Currently, there are two metrics for measuring the traffic in topic

[jira] [Commented] (KAFKA-14906) Extract the coordinator service log from server log

[ https://issues.apache.org/jira/browse/KAFKA-14906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17712337#comment-17712337 ] hudeqi commented on KAFKA-14906: This change will be reintroduced in version 4.x. > Extract the

[jira] [Reopened] (KAFKA-14906) Extract the coordinator service log from server log

[ https://issues.apache.org/jira/browse/KAFKA-14906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hudeqi reopened KAFKA-14906: > Extract the coordinator service log from server log > --- >

  1   2   >