Hi Haruki Okada: Thanks for commenting more ideas. For the naming. Maybe it is personal view for which is better. For the Admin API's approach. it can't solve the issue for Producer's warmup and not every API can call the API with high permissions. For the approach: retry calling partitionsFor until metadata-response. It can meet the requirement but it is not graceful method. In local's project, I reach the goal by java reflection And aslo I think it is not graceful method. So I try to propose one public method.
I agree with that we don't want to involve too many timeout related configure such as the parameter in getCluster. So maybe I can complete the discuss of KIP912. then move back to this thread. Anyway. thanks for your comment so that I aware that It is better for me to not using timeout control parameter in the method. Welcome for your more thought about it. And also we can have more discussion about the KIP912. I want to introduce two configures to decouple timeout control of metadata fetching and append operation. By default, no influence happen on the existed behavior if not set them. Haruki Okada <ocadar...@gmail.com> 于2023年3月9日周四 11:47写道： > Thanks for your explanation. > > > Thus, The code will look strange to call partitionsFor(topic) > > Hmm is that so? > As the javadoc for `partitionsFor` states, it is simply for getting > partition metadata for the topic, so I think nothing is strange even if we > use it for "warmup" metadata. > (And if so, `getCluster` also looks strange) > > > print some useful information when startup > > This sounds like trying to solve a different problem from the > initial motivation (warmup metadata). > For this particular problem, we can just use Admin API's corresponding > methods. > > > partitionsFor(topic) using the maxBlockTimeMs > > I can understand the intention though, this is just a "block time" for the > caller thread and metadata-request is being sent individually on Sender > thread, so we can just retry calling partitionsFor until metadata-response > is eventually received and we get successful metadata even when it timed > out. > > So I'm not sure if it makes sense to add a new API or timeout config (for > KIP-912), considering KafkaProducer already has many timeout parameters so > it could introduce another complexity. > > 2023年3月9日(木) 12:18 jian fu <fujian1...@gmail.com>: > > > Hi Haruki Okada: > > > > There is another KIP912 discussion related to this one. Welcome to give > > some comments/suggestions. > > > > Thanks. > > > > I think if the 912 is done. New method getCluster can use the new config > > directly with time parameter removed. > > > > WDTY? > > > > [DISCUSS] KIP-912: Support decreasing send's block time without worrying > > about metadata's fetch-Apache Mail Archives > > <https://lists.apache.org/thread/jq2fb8ylwxb2ojgvo5qdc57mgrmvxybj> > > > > jian fu <fujian1...@gmail.com> 于2023年3月9日周四 11:11写道： > > > > > Hi Okada Haruki: > > > > > > Thanks for your comment. > > > > > > I can use it partitionsFor(topic) for the goal, thus there are two > > reasons > > > why I don't choose it and propose to add new dedicated method: > > > 1) Consider how to use the method to solve the issue, We should call it > > in > > > application's startup process before any record sent. Thus, The code > will > > > look strange to call partitionsFor(topic) . So I suggest to add one > > > common method such as getCluster so that you can get and print some > > useful > > > information when startup with the goal reached. It also can provide > more > > > information self compare with partitionsFor. > > > 2) partitionsFor(topic) using the maxBlockTimeMs as the max blocking > > > time. For the metadata's fetching, I will take a lot of time so that we > > > must set maxBlockTimeMs to a big value (at least > time for metadata). > > > Thus consider that the send method is async. Most of application like > to > > > reduce the maxBlockTimeMs. It is conflict time requirement. So we need > > > one new blocking time as parameter of the method. I don't want to > change > > > the existing interface. > > > So based on above reasons. I suggest to add new method with time > control > > > parameter. > > > WDTY? > > > > > > Thanks. > > > > > > > > > Haruki Okada <ocadar...@gmail.com> 于2023年3月9日周四 10:19写道： > > > > > >> You can just use Producer#partitionsFor > > >> > > >> 2023年3月9日(木) 11:13 jian fu <fujian1...@gmail.com>: > > >> > > >> > Hi All: > > >> > > > >> > If anyone can help to give some comments or suggestions for the > > >> proposal. > > >> > Thanks in advance! > > >> > > > >> > Regards > > >> > Jian > > >> > > > >> > jian fu <fujian1...@gmail.com> 于2023年3月6日周一 17:00写道： > > >> > > > >> > > Hi Everyone: > > >> > > Nice to meet you. > > >> > > > > >> > > I created one KIP to request your review. > > >> > > KIP-913: add new method to provide possibility for accelerate > first > > >> > > record's sending > > >> > > < > > >> > > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-913%3A+add+new+method+to+provide+possibility+for+accelerate+first+record%27s+sending > > >> > > > > >> > > The example PR: > > >> > > *https://github.com/apache/kafka/pull/13320/files > > >> > > <https://github.com/apache/kafka/pull/13320/files>* > > >> > > > > >> > > Thanks. > > >> > > > > >> > > Regards > > >> > > Jian > > >> > > > > >> > > > > >> > > > >> > -- > > >> > Regards Fu.Jian > > >> > ------------------------------ > > >> > Cisco Communications, Inc. > > >> > > > >> > > >> > > >> -- > > >> ======================== > > >> Okada Haruki > > >> ocadar...@gmail.com > > >> ======================== > > >> > > > > > > > > > -- > > > Regards Fu.Jian > > > ------------------------------ > > > Cisco Communications, Inc. > > > > > > > > > > -- > > Regards Fu.Jian > > ------------------------------ > > Cisco Communications, Inc. > > > > > -- > ======================== > Okada Haruki > ocadar...@gmail.com > ======================== > -- Regards Fu.Jian ------------------------------ Cisco Communications, Inc.
