Hi everyone, Thanks for all your feedback. So far, there has been no negative feedback. I would like to start a vote on this PIP.
Thanks, Zike Yang On Wed, Jul 31, 2024 at 3:37 PM Yunze Xu <x...@apache.org> wrote: > > +1 (binding) > > Regarding the questions from Heesung, the customized load manager > could implement its own lookup logic when the `LookupOptions` has a > specific property. > > For example, given a topic "my-topic" and two brokers with > "lookup.broker" as "A" and "B". > - The client with lookup property "broker=A" will receive the response > that the owner is broker-0 > - The client with lookup property "broker=B" will receive the response > that the owner is broker-1 > - The client without any lookup property will receive the response > that the owner is the bundle's owner determined by the built-in load > manager > > Thanks, > Yunze > > On Tue, Jul 30, 2024 at 7:22 PM Zike Yang <z...@apache.org> wrote: > > > > Hi everyone, Thanks for your comments. > > > > > 1. Given that the current pulsar assigns topics to brokers at the > > bundle level, what happens with a topic lookup with rack info(rack A) > > for the bundle that's already assigned to a different rack(rack B)? > > > > In this case, the bundle has already been assigned to the specific > > broker. Then, the rack info for other clients shouldn't be respected. > > The customized load manager(rack-aware load manager) will still > > redirect the topic lookup to the rack B broker. > > However, an improved implementation would be to decide the best rack > > to act as the owner based on the current load conditions. > > > > > 2. Given that the latest load shedders(TransferShedder and AvgShedder) > > determine the destination brokers from the leader, how would the > > leader make sure to unload bundles(topics) to the brokers in the same > > rack? > > > > The rack info could be treated as an affinity property. When facing > > load imbalance, rack-info-based decisions may need to yield to > > load-based decisions. > > > > The rack-aware lookup scenario is an example of usage for this > > proposal. This proposal will not cover the detailed implementation of > > the rack-aware load manager. It focuses only on exposing certain > > interface capabilities to enable features like rack-aware lookup > > functionality. > > > > Thanks, > > Zike Yang > > > > On Sat, Jul 27, 2024 at 12:20 AM Heesung Sohn <hees...@apache.org> wrote: > > > > > > Although I agree with this direction, having the config in the lookup > > > requests, I have the following questions. > > > > > > 1. Given that the current pulsar assigns topics to brokers at the > > > bundle level, what happens with a topic lookup with rack info(rack A) > > > for the bundle that's already assigned to a different rack(rack B)? > > > 2. Given that the latest load shedders(TransferShedder and AvgShedder) > > > determine the destination brokers from the leader, how would the > > > leader make sure to unload bundles(topics) to the brokers in the same > > > rack? > > > > > > > > > Thanks, > > > Heesung > > > > > > On Fri, Jul 26, 2024 at 8:29 AM Heesung Sohn <hees...@apache.org> wrote: > > > > > > > > +1 (not binding) > > > > > > > > Heesung > > > > > > > > On Thu, Jul 25, 2024 at 7:52 PM Jie crossover <crossover...@gmail.com> > > > > wrote: > > > > > > > > > > +1 > > > > > I left some comments in the PR. > > > > > -- > > > > > Best Regards！ > > > > > crossoverJie > > > > > > > > > > > > > > > Zike Yang <z...@apache.org> 于2024年7月25日周四 11:15写道： > > > > > > > > > > > Hi, all, > > > > > > > > > > > > I proposed a new proposal to add client properties support for the > > > > > > lookup: https://github.com/apache/pulsar/pull/23075 > > > > > > > > > > > > PTAL and share your thoughts. Thanks! > > > > > > > > > > > > BR, > > > > > > Zike Yang > > > > > >
