Re: [VOTE] PIP-276: Add metric `pulsar_topic_load_times
Close the vote with 4(+1 binding) 2(+1 non-binding) 0(-1) binding: Hang Yunze Mattison Penghui non-binding Yubiao Asaf Regards Jiwei Guo (Tboy) On Mon, Jun 26, 2023 at 10:30 PM Hang Chen wrote: > +1 (binding) > > Thanks, > Hang > > Yunze Xu 于2023年6月26日周一 19:59写道： > > > > +1 (binding) > > > > Thanks, > > Yunze > > > > > > > > > > > On Jun 20, 2023, at 10:53, mattisonc...@gmail.com wrote: > > > > > > +1(binding) > > > > > > Best, > > > Mattison > > > On 20 Jun 2023 at 10:45 +0800, PengHui Li , wrote: > > >> +1 (binding) > > >> > > >> Thanks, > > >> Penghui > > >> > > >> On Tue, Jun 20, 2023 at 10:40 AM Yubiao Feng > > >> wrote: > > >> > > >>> Voting +1 (non-binding) > > >>> > > >>> Thanks > > >>> Yubiao Feng > > >>> > > >>> On Mon, Jun 19, 2023 at 5:21 PM Asaf Mesika > wrote: > > >>> > > > Voting +1 (non-binding) > > > > > > On Fri, Jun 16, 2023 at 12:23 PM guo jiwei > wrote: > > > > > >>> @Asaf Thanks, I have addressed the comment. > > >>> > > >>> Regards > > >>> Jiwei Guo (Tboy) > > >>> > > >>> > > >>> On Fri, Jun 16, 2023 at 3:55 AM Asaf Mesika < > asaf.mes...@gmail.com> > > > wrote: > > >>> > > > -1 (non-binding) > > > > > > I'm perfectly ok with the idea; just please fix the document. > It > > >>> looks > > >>> too > > > messy. Even 1 paragraph changes can look neat and clean. > > > I left notes in the draft PR you opened for the pip. > > > > > > I'll change my non-binding vote once that's done. > > > > > > On Thu, Jun 15, 2023 at 11:07 AM guo jiwei < > techno...@apache.org> > > > wrote: > > > > > >>> Hi, community: > > >>> The metrics are all started with `pulsar_`, so that both > users > > > and > > >>> operators can quickly find the metrics of the entire system > through > > >>> this prefix. However, due to some other reasons, it was > found that > > >>> `topic_load_times` was missing the prefix, so want to get it > right. > > >>> In the master branch : > > >>> * `pulsar_topic_load_times`: Add this new metric which has > the > > >>> same > > >>> meaning as `topic_load_times` > > >>> * `topic_load_times`: Mark this metric as deprecated and > > >>> remove > > >>> it > > > in > > >>> the next version > > >>> > > >>> PIP: https://github.com/apache/pulsar/pull/20518 > > >>> > > >>> Regards > > >>> Jiwei Guo (Tboy) > > >>> > > > > > >>> > > > > > >>> > > >
Re: [DISCUSS] Release Pulsar 3.0.1
Hi Zike, I have cherry-picked 3 PRs intro branch-3.0. All of them of well-understand bugs and performance issues. https://github.com/apache/pulsar/pull/20647 https://github.com/apache/pulsar/pull/20669 https://github.com/apache/pulsar/pull/20607 Thanks, Penghui On Fri, Jun 30, 2023 at 2:48 PM Yubiao Feng wrote: > Hi Zike > > > https://github.com/apache/pulsar/pull/20690 > > cherry-picked into branch-3.0 > > Thanks > Yubiao Feng > > On Fri, Jun 30, 2023 at 12:37 PM Yubiao Feng > wrote: > > > Hi Zike > > > > There is a bug fix involving a regression: > > - https://github.com/apache/pulsar/pull/20690 > > > > Thanks > > Yubiao Feng > > > > On Thu, Jun 1, 2023 at 7:38 PM Zike Yang wrote: > > > >> Hi all, > >> > >> I would like to propose releasing the Pulsar 3.0.1. > >> > >> Currently, there are 95 new commits in branch-3.0: > >> https://github.com/apache/pulsar/compare/v3.0.0...branch-3.0 > >> > >> And we have found that there is an issue with the pulsar-all:3.0.0 > >> image: https://lists.apache.org/thread/phcrm6czhyo7po6qncojk46hkytswblj > >> > >> We need to cut a new release. Please let me know if you have any > >> important fixes that need to be included in Pulsar 3.0.1. > >> > >> Thanks, > >> Zike Yang > >> > > >
Re: [DISCUSS] Cherry-pick PR-16059 to 2.10 to prevent infinite unloading
> `removeMostServicingBrokersForNamespace ` is introduced by [1] to solve the problem that when all bundles in a particular namespace belong to 1 or few machines, customers owning that namespace will be heavily impacted if that broker goes down. Of course, this PR caused the infinite unloading issue and we need to fix it. Thanks for the context. It looks like we can also try to fix the infinite unloading issue. Now, the broker is unloading the bundles without checking the distribution of the bundles under a namespace, but it will check when finding a new owner. Is it possible to check the bundle distribution before unloading the bundles to avoid infinite unloading? Regards, Penghui On Sun, Jul 2, 2023 at 3:28 PM Enrico Olivelli wrote: > +1 > > Enrico > > Il Dom 2 Lug 2023, 06:19 Hang Chen ha scritto: > > > +1 for cherry-picking it to branch-2.10. We have a flag to control > > whether to enable or disable it. > > > > `removeMostServicingBrokersForNamespace ` is introduced by [1] to > > solve the problem that when all bundles in a particular namespace > > belong to 1 or few machines, customers owning that namespace will be > > heavily impacted if that broker goes down. Of course, this PR caused > > the infinite unloading issue and we need to fix it. > > > > > I agree with making it false for the next major version release by > > default. > > We'd better remove the config in the next version instead of change > > the default value to `false`, which will make Pulsar's configuration > > keep increasing. > > > > Thanks, > > Hang > > > > [1] https://github.com/apache/pulsar/pull/388 > > > > PengHui Li 于2023年7月1日周六 09:38写道： > > > > > > +1 for cherry-pick to branch-2.10 since users don't have a workaround > > > for this issue, and the change is well-understand, low risk. > > > > > > I agree with making it false for the next major version release by > > default. > > > > > > Thanks, > > > Penghui > > > > > > On Sat, Jul 1, 2023 at 9:26 AM Heesung Sohn > > > wrote: > > > > > > > Hi dev, > > > > > > > > I realized that `removeMostServicingBrokersForNamespace` func in the > > broker > > > > selection logic can cause infinite unloading. > > > > > > > > Suppose an overloaded broker unloaded a bundle and only has the > minimum > > > > number of bundles(in that namespace) among brokers. In that case, the > > > > selection logic (`removeMostServicingBrokersForNamespace`) will > filter > > out > > > > other brokers and always reassign the bundle to the previous broker. > > This > > > > will cause infinite unloading(like a boomerang). > > > > > > > > To mitigate this issue, we need to cherry-pick this PR to disable > this > > > > logic by the config. > > > > https://github.com/apache/pulsar/pull/16059 > > > > > > > > And we probably want to disable this > > > > `removeMostServicingBrokersForNamespace` logic by default. > > > > > > > > Regards, > > > > Heesung > > > > > > >
Re: [DISCUSS] Cherry-pick PR-16059 to 2.10 to prevent infinite unloading
+1 Enrico Il Dom 2 Lug 2023, 06:19 Hang Chen ha scritto: > +1 for cherry-picking it to branch-2.10. We have a flag to control > whether to enable or disable it. > > `removeMostServicingBrokersForNamespace ` is introduced by [1] to > solve the problem that when all bundles in a particular namespace > belong to 1 or few machines, customers owning that namespace will be > heavily impacted if that broker goes down. Of course, this PR caused > the infinite unloading issue and we need to fix it. > > > I agree with making it false for the next major version release by > default. > We'd better remove the config in the next version instead of change > the default value to `false`, which will make Pulsar's configuration > keep increasing. > > Thanks, > Hang > > [1] https://github.com/apache/pulsar/pull/388 > > PengHui Li 于2023年7月1日周六 09:38写道： > > > > +1 for cherry-pick to branch-2.10 since users don't have a workaround > > for this issue, and the change is well-understand, low risk. > > > > I agree with making it false for the next major version release by > default. > > > > Thanks, > > Penghui > > > > On Sat, Jul 1, 2023 at 9:26 AM Heesung Sohn > > wrote: > > > > > Hi dev, > > > > > > I realized that `removeMostServicingBrokersForNamespace` func in the > broker > > > selection logic can cause infinite unloading. > > > > > > Suppose an overloaded broker unloaded a bundle and only has the minimum > > > number of bundles(in that namespace) among brokers. In that case, the > > > selection logic (`removeMostServicingBrokersForNamespace`) will filter > out > > > other brokers and always reassign the bundle to the previous broker. > This > > > will cause infinite unloading(like a boomerang). > > > > > > To mitigate this issue, we need to cherry-pick this PR to disable this > > > logic by the config. > > > https://github.com/apache/pulsar/pull/16059 > > > > > > And we probably want to disable this > > > `removeMostServicingBrokersForNamespace` logic by default. > > > > > > Regards, > > > Heesung > > > >
