*Hi Luck:* Thank you for taking the time to review.
*For discuss 1: * *"remote.log.metadata.initialization.retry.max.timeout.ms <http://remote.log.metadata.initialization.retry.max.timeout.ms/>" timer will be* *> started after the broker ready (i.e. the connection is ready to accept* *> connection), right? "* *right. * *For discuss 2：* *"we should mention it in "Compatibility" section and the config* *> description in "remote.log.metadata.initialization.retry.max.timeout.ms <http://remote.log.metadata.initialization.retry.max.timeout.ms/>"."* *Ok, I updated the KIP wiki and the PR.* *Hi Anatolii：* Thank you for taking the time to review the code chang: *For discuss 1: * *" does it make senseto have "registerBrokerReadyCallback" as a private method"* *Yes, I removed the private modifier. At least it helps with visibility for testing. * Thanks for review and suggestion. Regards Jian jian fu <[email protected]> 于2025年10月2日周四 10:09写道： > > *Hi Luck:* > > Thank you for taking the time to review. > > *For discuss 1: * > *"remote.log.metadata.initialization.retry.max.timeout.ms > <http://remote.log.metadata.initialization.retry.max.timeout.ms/>" timer > will be* > > *> started after the broker ready (i.e. the connection is ready to accept* > *> connection), right? "* > *right. * > > *For discuss 2：* > *"we should mention it in "Compatibility" section and the config* > *> description in "remote.log.metadata.initialization.retry.max.timeout.ms > <http://remote.log.metadata.initialization.retry.max.timeout.ms/>"."* > *Ok, I updated the KIP wiki and the PR.* > > *Hi Anatolii：* > > Thank you for taking the time to review the code chang: > > *For discuss 1: * > > *" does it make senseto have "registerBrokerReadyCallback" as a private > method"* > > *Yes, I removed the private modifier. At least it helps with visibility > for testing. * > Thanks for review and suggestion. > > Regards > Jian > > > Anatolii Popov <[email protected]> 于2025年9月30日周二 19:08写道： > >> Hi Jian, >> >> Thanks for the update. >> The solution makes sense to me. >> But on top of Luke's comment I have one more question: does it make sense >> to have "registerBrokerReadyCallback" as a private method? I had the >> impression that it could be used at least in testing as well to simplify >> the waiting logic but that would require the method to be accessible from >> there. >> >> Regards, >> Anatolii. >> >> On Tue, Sep 30, 2025 at 7:37 AM Luke Chen <[email protected]> wrote: >> >> > Hi Jian, >> > >> > Thanks for the KIP. >> > This solution makes sense to me. >> > >> > One minor comment, after this change, the " >> > remote.log.metadata.initialization.retry.max.timeout.ms" timer will be >> > started after the broker ready (i.e. the connection is ready to accept >> > connection), right? >> > So we should mention it in "Compatibility" section and the config >> > description in "remote.log.metadata.initialization.retry.max.timeout.ms >> ". >> > >> > Thank you. >> > Luke >> > >> > On Tue, Sep 30, 2025 at 12:19 PM jian fu <[email protected]> wrote: >> > >> >> Hi Anatolii Popov: >> >> >> >> Thanks for your comments and suggestions and sorry for my delay >> response. >> >> I think it makes sense. So I add new dedicated interface for this. >> >> >> >> Thanks for your review again. >> >> >> >> Regards >> >> Jian >> >> >> >> Anatolii Popov <[email protected]> 于2025年8月22日周五 >> 22:28写道： >> >> >> >> > Hi Jian, >> >> > >> >> > Thanks for the KIP! >> >> > >> >> > I went through the proposed solution and the discussions on GitHub >> and I >> >> > wonder if you considered a more generic solution for notifying not >> only >> >> > RLMM but other potential listeners as well? >> >> > I think there are several places that could benefit from this and >> also >> >> it >> >> > could improve testability quite a bit. >> >> > >> >> > Regards, >> >> > Anatolii. >> >> > >> >> > On Mon, Aug 18, 2025 at 11:56 AM jian fu <[email protected]> >> wrote: >> >> > >> >> > > Hi Kamal >> >> > > Thanks for your comments! >> >> > > Regards >> >> > > Jian >> >> > > >> >> > > Kamal Chandraprakash <[email protected]> >> 于2025年8月12日周二 >> >> > > 18:36写道： >> >> > > >> >> > > > Hi Jian, >> >> > > > >> >> > > > Thanks for the KIP! >> >> > > > >> >> > > > The newly introduced onBrokerReadyForRequests API in the >> >> > > > RemoteLogMetadataManager (RLMM) >> >> > > > is primarily needed for the topic-based RLMM (TBRLMM) >> >> implementation. >> >> > > This >> >> > > > API may not be necessary >> >> > > > for other implementations that do not rely on Kafka to store >> remote >> >> log >> >> > > > metadata. Given that TBRLMM is >> >> > > > packaged as the default (out-of-the-box) implementation, this >> design >> >> > > > approach seems reasonable to me. >> >> > > > >> >> > > > Thanks, >> >> > > > Kamal >> >> > > > >> >> > > > On Fri, Jul 25, 2025 at 11:58 AM jian fu <[email protected]> >> >> wrote: >> >> > > > >> >> > > > > Hi Everyone: >> >> > > > > Nice to meet you. >> >> > > > > >> >> > > > > I created one KIP to request your review. >> >> > > > > KIP-1197: Introduce new method to improve the >> >> > > > > TopicBasedRemoteLogMetadataManager's initialization >> >> > > > > < >> >> > > > > >> >> > > > >> >> > > >> >> > >> >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1197%3A+Introduce+new+method+to+improve+the+TopicBasedRemoteLogMetadataManager%27s+initialization >> >> > > > > > >> >> > > > > >> >> > > > > The PR: >> >> > > > > https://github.com/apache/kafka/pull/20203/files >> >> > > > > >> >> > > > > Thanks. >> >> > > > > >> >> > > > > >> >> > > > > Regards Fu.Jian >> >> > > > > >> >> > > > >> >> > > >> >> > > >> >> > > -- >> >> > > >> >> > >> >> > >> >> > -- >> >> > Anatolii Popov >> >> > Senior Software Developer, *Aiven OY* >> >> > m: +358505126242 >> >> > w: aiven.io e: [email protected] >> >> > <https://www.facebook.com/aivencloud> >> >> > <https://www.linkedin.com/company/aiven/> < >> >> https://twitter.com/aiven_io> >> >> > >> >> >> > >> > > > -- > Regards Fu.Jian > ------------------------------ > Cisco Communications, Inc. > > -- Regards Fu.Jian ------------------------------ Cisco Communications, Inc.
