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