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> >> > >> >
