Hi Chia-Ping:
Thanks for your suggestion.
1: " having`TopicBasedRemoteLogMetadataManager` extend it "- I think it is
a good idea that we can avoid involve it into all the
RemoteLogMetadataManager even we can using default method.
the sever part can been changed to :
rlm.remoteLogMetadataManager() match {
case callback: BrokerReadyCallback =>
registerBrokerReadyCallback(callback)
case _ => // RemoteLogMetadataManager doesn't implement
BrokerReadyCallback, skip registration
}
2: making the new interface non-public
currently. It seems it isn't possible because the interface is involved in
two different package. It’s challenging to handle this while keeping the
code elegant (any other ideas?).
So I suggest we can keep it public after all the interface method is very
simple.
org.apache.kafka.server.log.remote.metadata.storage.TopicBasedRemoteLogMetadataManager;
kafka.server.BrokerServer
Thanks for your discussion!
Chia-Ping Tsai <[email protected]> 于2025年10月21日周二 23:28写道：
> hi Jian
>
> thanks for your response.
>
> How about making the new interface non-public and having
> `TopicBasedRemoteLogMetadataManager` extend it? The broker could then still
> execute the callback via the interface
>
> This is beneficial because:
>
> 1. we can easily make the interface public later if more use cases emerge
>
> 2. It simplifies development by avoiding a KIP and minimizing maintenance
> for a potentially specific-use public interface
>
> Best,
>
> Chia-Ping
>
>
> jian fu <[email protected]> 於 2025年10月21日 週二 下午10:36寫道：
>
> > Hi Chia-Ping:
> >
> > Thanks for your comments.
> >
> > Actually, I did consider this idea at the very beginning. As you
> mentioned,
> > such a change wouldn’t require going through the KIP process. However, I
> > didn’t adopt this approach because, from an implementation perspective,
> it
> > would likely lead to logic along the lines of if (xxx instance of
> > TopicBasedRemoteLogMetadataManager) then "special handle", which doesn’t
> > seem very elegant.
> >
> > Regarding the public interface, I hadn’t initially thought of making it
> > fully public; I only added a default method to the interface (though it
> > still needs the KIP). But, as Abb pointed out, making it a public
> interface
> > could be beneficial since many places could use it and gain from it, and
> I
> > do agree with this perspective. After all, using a topic as the storage
> > medium is certainly not limited to tiered storage.
> >
> > Ultimately, after considering everyone’s feedback and ideas, I
> implemented
> > it in the current way.
> >
> > Anyway, Thank you very much for your suggestion!
> >
> > Regards
> >
> > Jian
> >
> > Chia-Ping Tsai <[email protected]> 于2025年10月21日周二 22:09写道：
> >
> > > hi jian
> > >
> > > thanks for the KIP. I have a major question.
> > >
> > > chia_00: It appears this approach currently works only for
> > > `TopicBasedRemoteLogMetadataManager`. Perhaps we could add specific
> > > handling for it directly within the broker server? The benefit would be
> > > avoiding a KIP and eliminating the need to maintain a "public" callback
> > > function.
> > >
> > > Best,
> > > Chia-Ping
> > >
> > > On 2025/07/25 06:28:24 jian fu 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
> > > >
> > >
> >
>
