from:"houxiaoyu"

Re: [ANNOUNCE] New Committer: Asaf Mesika

2024-02-21 Thread houxiaoyu

Congratulations!

Best,
houxiaoyu

Max Xu  于2024年2月21日周三 17:32写道：
>
> Congratulations, Asaf! Well deserved.
>
>
> Best,
> Max Xu
>
>
> On Wed, Feb 21, 2024 at 12:51 AM Lari Hotari  wrote:
>
> > The Apache Pulsar Project Management Committee (PMC) has invited
> > Asaf Mesika https://github.com/asafm to become a committer and we
> > are pleased to announce that he has accepted.
> >
> > Welcome and Congratulations, Asaf Mesika!
> >
> > Please join us in congratulating and welcoming Asaf onboard!
> >
> > Best Regards,
> >
> > Lari Hotari
> > on behalf of the Pulsar PMC
> >

Re: [VOTE] PIP-335: Oxia metadata support

2024-02-06 Thread houxiaoyu

+1 nonbinding

Thanks,
Xiaoyu Hou

太上玄元道君  于2024年2月6日周二 15:59写道：
>
> +1 nonbinding
>
> Matteo Merli 于2024年2月6日 周二04:40写道：
>
> > https://github.com/apache/pulsar/pull/22009
> >
> > -
> >
> > # PIP-335: Support Oxia metadata store plugin
> >
> > # Motivation
> >
> > Oxia is a scalable metadata store and coordination system that can be used
> > as the core infrastructure
> > to build large scale distributed systems.
> >
> > Oxia was created with the primary goal of providing an alternative Pulsar
> > to replace ZooKeeper as the
> > long term preferred metadata store, overcoming all the current limitations
> > in terms of metadata
> > access throughput and data set size.
> >
> > # Goals
> >
> > Add a Pulsar MetadataStore plugin that uses Oxia client SDK.
> >
> > Users will be able to start a Pulsar cluster using just Oxia, without any
> > ZooKeeper involved.
> >
> > ## Not in Scope
> >
> > It's not in the scope of this proposal to change any default behavior or
> > configuration of Pulsar.
> >
> > # Detailed Design
> >
> > ## Design & Implementation Details
> >
> > Oxia semantics and client SDK were already designed with Pulsar and
> > MetadataStore plugin API in mind, so
> > there is not much integration work that needs to be done here.
> >
> > Just few notes:
> >  1. Oxia client already provides support for transparent batching of read
> > and write operations,
> > so there will be no use of the batching logic in
> > `AbstractBatchedMetadataStore`
> >  2. Oxia does not treat keys as a walkable file-system like interface, with
> > directories and files. Instead
> > all the keys are independent. Though Oxia sorting of keys is aware of
> > '/' and provides efficient key
> > range scanning operations to identify the first level children of a
> > given key
> >  3. Oxia, unlike ZooKeeper, doesn't require the parent path of a key to
> > exist. eg: we can create `/a/b/c` key
> > without `/a/b` and `/a` existing.
> > In the Pulsar integration for Oxia we're forcing to create all parent
> > keys when they are not there. This
> > is due to several places in BookKeeper access where it does not create
> > the parent keys, though it will
> > later make `getChildren()` operations on the parents.
> >
> > ## Other notes
> >
> > Unlike in the ZooKeeper implementation, the notification of events is
> > guaranteed in Oxia, because the Oxia
> > client SDK will use the transaction offset after server reconnections and
> > session restarted events. This
> > will ensure that brokers cache will always be properly invalidated. We will
> > then be able to remove the
> > current 5minutes automatic cache refresh which is in place to prevent the
> > ZooKeeper missed watch issue.
> >
> > # Links
> >
> > Oxia: https://github.com/streamnative/oxia
> > Oxia Java Client SDK: https://github.com/streamnative/oxia-java
> >
> >
> > --
> > Matteo Merli
> > 
> >

Re: [VERIFY] Pulsar Release 3.2.0 Candidate 1

2024-01-09 Thread houxiaoyu

+1 (non-binding)


- Checksum and signatures
- Build on Mac, using JDK17.0.8
- Run Pulsar standalone and produce/consume case

Thanks,
Xiaoyu Hou

guo jiwei  于2024年1月9日周二 16:15写道：
>
> This is the first release candidate for Apache Pulsar version 3.2.0.
>
> It fixes the following issues:
> https://github.com/apache/pulsar/milestone/36?closed=1
>
> *** Please download, test and verify on this release. This release
> candidate verification will stay open until Jan 15 ***
>
> Note that we are verifying upon the source (tag), binaries are provided for
> convenience.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-3.2.0-candidate-1/
>
> SHA-512 checksums:
>
> cf4e661d78f4194f4cde88e102bc9a734e2777613c5315f09115d64236759fbc5ded868c7e0cc3d07813c3fd34b1b123ca6f06f4335d6c9c96393789c6eda5bc
>
> apache-pulsar-3.2.0-bin.tar.gz
>
> 6ebe72de801db9a3f51dde39587b93d947904856385a21020319edb6988776fd68ec079471bcce5db17ea1b79c58e22ebf89a854debb40437ad9dc2bc2350357
>
> apache-pulsar-3.2.0-src.tar.gz
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1259/
>
> The tag to verify:
> v3.2.0-candidate-1 (4ab09374ade3c1402812c3c6be0d07984ab373a4)
> https://github.com/apache/pulsar/commits/v3.2.0-candidate-1/
>
> Pulsar's KEYS file containing PGP keys you use to sign the release:
> https://dist.apache.org/repos/dist/dev/pulsar/KEYS
>
> Docker images:
>
> pulsar images:
> https://hub.docker.com/layers/technoboy8/pulsar/3.2.0-4ab0937/images/sha256-06d35d60f3bd4f954b8b1b6f4cc4f663556ace5da097173f41a61622e81a76b9?context=repo
> 
> pulsar-all images:
> https://hub.docker.com/layers/technoboy8/pulsar-all/3.2.0-4ab0937/images/sha256-a6f87bc5fd8025f096f35f26d47303267452e35d92f9f974d8536b61543ddbeb?context=repo
>
> Please download the source package, and follow the README to build
> and run the Pulsar standalone service.
>
> Note that this RC doesn't require a formal vote, but we would also
> appreciate your feedback with +1/-1. And please provide specific
> comments if your feedback is not +1.
>
>
> Regards
> Jiwei Guo (Tboy)

[ANNOUNCE] Apache Pulsar 3.1.2 released

2024-01-03 Thread houxiaoyu

The Apache Pulsar team is proud to announce Apache Pulsar version 3.1.2.

Pulsar is a highly scalable, low latency messaging platform running on
commodity hardware. It provides simple pub-sub semantics over topics,
guaranteed at-least-once delivery of messages, automatic cursor management
for subscribers, and cross-datacenter replication.

For Pulsar release details and downloads, visit:

https://pulsar.apache.org/download

Release Notes are at:
https://pulsar.apache.org/release-notes

We would like to thank the contributors that made the release possible.

Regards,

The Pulsar Team

[ANNOUNCE] Apache Pulsar 3.1.2 released

2024-01-03 Thread houxiaoyu

The Apache Pulsar team is proud to announce Apache Pulsar version 3.1.2.

Pulsar is a highly scalable, low latency messaging platform running on
commodity hardware. It provides simple pub-sub semantics over topics,
guaranteed at-least-once delivery of messages, automatic cursor management
for subscribers, and cross-datacenter replication.

For Pulsar release details and downloads, visit:

https://pulsar.apache.org/download

Release Notes are at:
https://pulsar.apache.org/release-notes

We would like to thank the contributors that made the release possible.

Regards,

The Pulsar Team

Re: [VOTE] Pulsar Release 3.1.2 Candidate 2

2024-01-01 Thread houxiaoyu

Thanks everyone!

The vote is now closed and the release was approved with
3 +1s(3 bindings);

Binding votes:
* Enrico Olivelli
* Jiwei Guo (Tboy)
* Penghui Li

PengHui Li  于2023年12月28日周四 16:32写道：

> +1 (binding)
>
> - Built from source
> - Checked the signatures
> - Run standalone
> - Checked producer and consumer
> - Verified the Cassandra connector
> - Verified the Stateful function
>
> Regards,
> Penghui
>
> On Mon, Dec 25, 2023 at 10:34 PM houxiaoyu  wrote:
>
> > bump
> >
> > Enrico Olivelli  于2023年12月18日周一 21:21写道：
> >
> > > +1 (binding)
> > >
> > > Built from sources
> > > Run some smoke tests with Pulsar standalone
> > > Verified checksums and signatures (I had to import KEYS, there was a
> new
> > > key)
> > >
> > > Enrico
> > >
> > > Il giorno mer 13 dic 2023 alle ore 09:42 guo jiwei
> > >  ha scritto:
> > > >
> > > > +1 (binding)
> > > >
> > > > - Checked the signatures
> > > > - Built from source
> > > > - Run standalone and check the produce, consume
> > > > - Verified Cassandra connector
> > > > - Verified stateful function
> > > >
> > > >
> > > > Regards
> > > > Jiwei Guo (Tboy)
> > > >
> > > >
> > > > On Sat, Dec 9, 2023 at 2:48 PM houxiaoyu 
> wrote:
> > > >
> > > > > This is the second release candidate for Apache Pulsar version
> 3.1.2.
> > > > >
> > > > > It fixes the following issues:
> > > > >
> > > > >
> > >
> >
> https://github.com/apache/pulsar/pulls?q=is%3Apr+is%3Amerged+label%3Arelease%2F3.1.2+label%3Acherry-picked%2Fbranch-3.1+
> > > > >
> > > > > *** Please download, test and vote on this release. This vote will
> > > > > stay open for at least 72 hours ***
> > > > >
> > > > > Note that we are voting upon the source (tag), binaries are
> provided
> > > > > for convenience.
> > > > >
> > > > > Source and binary files:
> > > > >
> > >
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-3.1.2-candidate-2/
> > > > >
> > > > > SHA-512 checksums:
> > > > >
> > > > > apache-pulsar-3.1.2-bin.tar.gz
> > > > >
> > > > >
> > >
> >
> 48e2d0069cd69c6f2bf5b5d5aa9fbc775436d3e160bd51645a6626fb86706ddba4901a5d6b87e29a57b9f19c0d0b8c22aef2dfa3d3525260ad55d0a39db6
> > > > >
> > > > > apache-pulsar-3.1.2-src.tar.gz
> > > > >
> > > > >
> > >
> >
> 4d29b1f707047d1bd55d8cb8aacb488517fbd82903fef57c9924180b62454725bdbdc53adf7af5d5caa4d57522a10d6eb15028fd929325b9cadd088a6e3de20a
> > > > >
> > > > > Maven staging repo:
> > > > >
> > >
> https://repository.apache.org/content/repositories/orgapachepulsar-1256/
> > > > >
> > > > > The tag to verify:
> > > > > v3.1.2-candidate-2 (c4196fba3ae107d74f9421d3f7ed11c0c245f10f)
> > > > > https://github.com/apache/pulsar/releases/tag/v3.1.2-candidate-2
> > > > >
> > > > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> > > > >
> > > > > Docker images:
> > > > >
> > > > > pulsar images:
> > > > > https://hub.docker.com/repository/docker/anonhxygo/pulsar
> > > > >
> > > > > pulsar-all images:
> > > > > https://hub.docker.com/repository/docker/anonhxygo/pulsar-all
> > > > >
> > > > > Please download the source package, and follow the README to build
> > > > > and run the Pulsar standalone service.
> > > > >
> > > > >
> > > > > Regards
> > > > > Xiaoyu Hou
> > > > >
> > >
> >
>

Re: [VOTE] Pulsar Release 3.1.2 Candidate 2

2023-12-25 Thread houxiaoyu

bump

Enrico Olivelli  于2023年12月18日周一 21:21写道：

> +1 (binding)
>
> Built from sources
> Run some smoke tests with Pulsar standalone
> Verified checksums and signatures (I had to import KEYS, there was a new
> key)
>
> Enrico
>
> Il giorno mer 13 dic 2023 alle ore 09:42 guo jiwei
>  ha scritto:
> >
> > +1 (binding)
> >
> > - Checked the signatures
> > - Built from source
> > - Run standalone and check the produce, consume
> > - Verified Cassandra connector
> > - Verified stateful function
> >
> >
> > Regards
> > Jiwei Guo (Tboy)
> >
> >
> > On Sat, Dec 9, 2023 at 2:48 PM houxiaoyu  wrote:
> >
> > > This is the second release candidate for Apache Pulsar version 3.1.2.
> > >
> > > It fixes the following issues:
> > >
> > >
> https://github.com/apache/pulsar/pulls?q=is%3Apr+is%3Amerged+label%3Arelease%2F3.1.2+label%3Acherry-picked%2Fbranch-3.1+
> > >
> > > *** Please download, test and vote on this release. This vote will
> > > stay open for at least 72 hours ***
> > >
> > > Note that we are voting upon the source (tag), binaries are provided
> > > for convenience.
> > >
> > > Source and binary files:
> > >
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-3.1.2-candidate-2/
> > >
> > > SHA-512 checksums:
> > >
> > > apache-pulsar-3.1.2-bin.tar.gz
> > >
> > >
> 48e2d0069cd69c6f2bf5b5d5aa9fbc775436d3e160bd51645a6626fb86706ddba4901a5d6b87e29a57b9f19c0d0b8c22aef2dfa3d3525260ad55d0a39db6
> > >
> > > apache-pulsar-3.1.2-src.tar.gz
> > >
> > >
> 4d29b1f707047d1bd55d8cb8aacb488517fbd82903fef57c9924180b62454725bdbdc53adf7af5d5caa4d57522a10d6eb15028fd929325b9cadd088a6e3de20a
> > >
> > > Maven staging repo:
> > >
> https://repository.apache.org/content/repositories/orgapachepulsar-1256/
> > >
> > > The tag to verify:
> > > v3.1.2-candidate-2 (c4196fba3ae107d74f9421d3f7ed11c0c245f10f)
> > > https://github.com/apache/pulsar/releases/tag/v3.1.2-candidate-2
> > >
> > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> > >
> > > Docker images:
> > >
> > > pulsar images:
> > > https://hub.docker.com/repository/docker/anonhxygo/pulsar
> > >
> > > pulsar-all images:
> > > https://hub.docker.com/repository/docker/anonhxygo/pulsar-all
> > >
> > > Please download the source package, and follow the README to build
> > > and run the Pulsar standalone service.
> > >
> > >
> > > Regards
> > > Xiaoyu Hou
> > >
>

Re: [VOTE] PIP-326: Create a BOM to ease dependency management

2023-12-22 Thread houxiaoyu

+1 non-binding

Best,
houxiaoyu

tison  于2023年12月23日周六 10:10写道：

> +1 binding
>
> Best,
> tison.
>
> 太上玄元道君  于2023年12月23日周六 09:06写道：
> >
> > +1 nonbinding
> >
> > Umut Bilal Okur 于2023年12月23日 周六00:13写道：
> >
> > > +1 (non-binding)
> > >
> > > Enrico Olivelli , 22 Ara 2023 Cum, 18:26
> tarihinde
> > > şunu yazdı:
> > >
> > > > +1 (binding)
> > > >
> > > > Enrico
> > > >
> > > > Il giorno ven 22 dic 2023 alle ore 02:46 Apurva Telang
> > > >  ha scritto:
> > > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > On Thu, Dec 21, 2023 at 4:30 PM Matteo Merli 
> > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matteo Merli
> > > > > > 
> > > > > >
> > > > > >
> > > > > > On Thu, Dec 21, 2023 at 4:24 PM Nicolò Boschi <
> boschi1...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1 binding
> > > > > > >
> > > > > > > Nicolò Boschi
> > > > > > >
> > > > > > >
> > > > > > > Il giorno gio 21 dic 2023 alle 21:21 Lari Hotari <
> > > lhot...@apache.org>
> > > > ha
> > > > > > > scritto:
> > > > > > >
> > > > > > > > +1 (binding)
> > > > > > > >
> > > > > > > > -Lari
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, 21 Dec 2023 at 22:10, Chris Bono 
> > > wrote:
> > > > > > > > >
> > > > > > > > > I'm starting the vote for PIP-326, since it has been
> reviewed
> > > by
> > > > > > > > > several members with no objections.
> > > > > > > > >
> > > > > > > > > PIP link: https://github.com/apache/pulsar/pull/21747
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > Chris
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Apurva Telang.
> > > >
> > >
>

[VOTE] Pulsar Release 3.1.2 Candidate 2

2023-12-08 Thread houxiaoyu

This is the second release candidate for Apache Pulsar version 3.1.2.

It fixes the following issues:
https://github.com/apache/pulsar/pulls?q=is%3Apr+is%3Amerged+label%3Arelease%2F3.1.2+label%3Acherry-picked%2Fbranch-3.1+

*** Please download, test and vote on this release. This vote will
stay open for at least 72 hours ***

Note that we are voting upon the source (tag), binaries are provided
for convenience.

Source and binary files:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-3.1.2-candidate-2/

SHA-512 checksums:

apache-pulsar-3.1.2-bin.tar.gz
48e2d0069cd69c6f2bf5b5d5aa9fbc775436d3e160bd51645a6626fb86706ddba4901a5d6b87e29a57b9f19c0d0b8c22aef2dfa3d3525260ad55d0a39db6

apache-pulsar-3.1.2-src.tar.gz
4d29b1f707047d1bd55d8cb8aacb488517fbd82903fef57c9924180b62454725bdbdc53adf7af5d5caa4d57522a10d6eb15028fd929325b9cadd088a6e3de20a

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachepulsar-1256/

The tag to verify:
v3.1.2-candidate-2 (c4196fba3ae107d74f9421d3f7ed11c0c245f10f)
https://github.com/apache/pulsar/releases/tag/v3.1.2-candidate-2

Pulsar's KEYS file containing PGP keys you use to sign the release:
https://dist.apache.org/repos/dist/dev/pulsar/KEYS

Docker images:

pulsar images:
https://hub.docker.com/repository/docker/anonhxygo/pulsar

pulsar-all images:
https://hub.docker.com/repository/docker/anonhxygo/pulsar-all

Please download the source package, and follow the README to build
and run the Pulsar standalone service.


Regards
Xiaoyu Hou

Re: [VOTE] Pulsar Release 3.1.2 Candidate 1

2023-12-07 Thread houxiaoyu

Thanks jiwei.

Drop this vote and I will raise the next candidate after fixing the bug

guo jiwei  于2023年12月7日周四 17:02写道：

> Hi
>  We find a regression in 3.0,  Apache/Pulsar/#17512
> <https://github.com/apache/pulsar/pull/17512> has fixed the data being
> deleted when offload met Metastore exception, but Apache/Pulsar/#17915
> <https://github.com/apache/pulsar/pull/17915> skip the logic, causing the
> broker to delete the data from the tiered storage.
>  I suggest dropping this vote and fix the issue then raise a new candidate.
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Sat, Dec 2, 2023 at 4:56 PM houxiaoyu  wrote:
>
> > This is the first release candidate for Apache Pulsar version 3.1.2.
> >
> > It fixes the following issues:
> >
> >
> https://github.com/apache/pulsar/pulls?q=is%3Apr+is%3Amerged+label%3Arelease%2F3.1.2+label%3Acherry-picked%2Fbranch-3.1+
> >
> > *** Please download, test and vote on this release. This vote will
> > stay open for at least 72 hours ***
> >
> > Note that we are voting upon the source (tag), binaries are provided
> > for convenience.
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-3.1.2-candidate-1/
> >
> > SHA-512 checksums:
> >
> >
> >
> 47e487de57c4354ed07a1690197eed9057e67ee85055d11c098ae6cff642b20e4966d43c3d52f449a942547d417dd20b94c353c7485cbd599f6f059147826f5f
> > apache-pulsar-3.1.2-bin.tar.gz
> >
> >
> >
> 664a5811788817c302c1e2a943f959339832ef77417e2ca566696948e330172ada878e1487402e9aff6a0a81a89b44404c797114eb2f27922f58831adfaa0582
> > apache-pulsar-3.1.2-src.tar.gz
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachepulsar-1255/
> >
> > The tag to verify:
> > v3.1.2-candidate-1 (9f110390ebd3ccaeb67adec9c51631e735414ccd)
> > https://github.com/apache/pulsar/releases/tag/v3.1.2-candidate-1
> >
> > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> >
> > Docker images:
> >
> > pulsar images:
> > https://hub.docker.com/repository/docker/anonhxygo/pulsar
> >
> > pulsar-all images:
> > https://hub.docker.com/repository/docker/anonhxygo/pulsar-all
> >
> > Please download the source package, and follow the README to build
> > and run the Pulsar standalone service.
> >
> >
> > Regards
> > houxiaoyu
> >
>

[VOTE] Pulsar Release 3.1.2 Candidate 1

2023-12-02 Thread houxiaoyu

This is the first release candidate for Apache Pulsar version 3.1.2.

It fixes the following issues:
https://github.com/apache/pulsar/pulls?q=is%3Apr+is%3Amerged+label%3Arelease%2F3.1.2+label%3Acherry-picked%2Fbranch-3.1+

*** Please download, test and vote on this release. This vote will
stay open for at least 72 hours ***

Note that we are voting upon the source (tag), binaries are provided
for convenience.

Source and binary files:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-3.1.2-candidate-1/

SHA-512 checksums:

47e487de57c4354ed07a1690197eed9057e67ee85055d11c098ae6cff642b20e4966d43c3d52f449a942547d417dd20b94c353c7485cbd599f6f059147826f5f
apache-pulsar-3.1.2-bin.tar.gz

664a5811788817c302c1e2a943f959339832ef77417e2ca566696948e330172ada878e1487402e9aff6a0a81a89b44404c797114eb2f27922f58831adfaa0582
apache-pulsar-3.1.2-src.tar.gz

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachepulsar-1255/

The tag to verify:
v3.1.2-candidate-1 (9f110390ebd3ccaeb67adec9c51631e735414ccd)
https://github.com/apache/pulsar/releases/tag/v3.1.2-candidate-1

Pulsar's KEYS file containing PGP keys you use to sign the release:
https://dist.apache.org/repos/dist/dev/pulsar/KEYS

Docker images:

pulsar images:
https://hub.docker.com/repository/docker/anonhxygo/pulsar

pulsar-all images:
https://hub.docker.com/repository/docker/anonhxygo/pulsar-all

Please download the source package, and follow the README to build
and run the Pulsar standalone service.


Regards
houxiaoyu

[DISCUSS] Release Pulsar 3.1.2

2023-11-26 Thread houxiaoyu

Hi all,

I would like to propose releasing the Pulsar 3.1.2.

It's over one month since the release of 3.1.1 and there are 56 new commits
in branch-3.1:
https://github.com/apache/pulsar/compare/v3.1.1...branch-3.1

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.1.2.


Regards
Xiaoyu Hou

Re: [ANNOUNCE] New Committer: Chris Bono

2023-11-20 Thread houxiaoyu

Congrats!

Thanks,
Xiaoyu Hou

Lari Hotari  于2023年11月20日周一 18:10写道：

> The Apache Pulsar Project Management Committee (PMC) has invited
> Chris Bono https://github.com/onobc to become a committer and we
> are pleased to announce that he has accepted.
>
> Welcome and Congratulations, Chris Bono!
>
> Please join us in congratulating and welcoming Chris Bono onboard!
>
> Best Regards,
>
> Lari Hotari
> on behalf of the Pulsar PMC
>

Re: [ANNOUNCE] Yubiao Feng as new PMC member in Apache Pulsar

2023-11-13 Thread houxiaoyu

Congrats

Thanks,
Xiaoyu Hou

Yunze Xu  于2023年11月13日周一 20:00写道：

> Congrats!
>
> Thanks,
> Yunze
>
> On Mon, Nov 13, 2023 at 6:15 PM Zixuan Liu  wrote:
> >
> > Congrats!
> >
> > Thanks,
> > Zixuan
> >
> > Cong Zhao  于2023年11月13日周一 18:01写道：
> >
> > > Congrats! Yubiao
> > >
> > > Thanks,
> > > Cong
> > >
> > > On 2023/11/13 07:36:27 mattison chao wrote:
> > > > Dear Community,
> > > >
> > > > We are thrilled to announce that Yubiao Feng
> > > https://github.com/poorbarcode has been invited and has accepted the
> role
> > > of a member of the Apache Pulsar Project Management Committee (PMC).
> > > >
> > > > Yubiao Feng has proven to be an invaluable asset to our community,
> > > consistently showcasing dedication and active engagement through
> > > substantial contributions. Beyond his noteworthy technical input,
> Yubiao
> > > plays a crucial role in meticulously reviewing pull requests, thereby
> > > ensuring the overall excellence of our project. We eagerly anticipate
> and
> > > appreciate his ongoing contributions. On behalf of the Pulsar PMC, we
> > > extend a heartfelt welcome and congratulations to Yubiao Feng.
> > > >
> > > > Sincerely,
> > > > Mattison
> > >
>

Re: [VOTE] PIP-301: Introduce LoadBalanceResources to unify the load-date CRUD

2023-09-21 Thread houxiaoyu

Thank you all.

Close this vote by 4 binding +1s:
- Jiwei Guo (Tboy)
- Penghui Li
- Mattison
- Bo
And 1 non-binding +1: Heesung Sohn

Regards
Xiaoyu Hou


Heesung Sohn  于2023年9月20日周三 23:52写道：

> +1 (non-binding)
>
> On Tue, Sep 19, 2023 at 10:25 PM 丛搏  wrote:
>
> > +1 (binding)
> >
> > Thanks,
> > Bo
> >
>

[VOTE] PIP-301: Introduce LoadBalanceResources to unify the load-date CRUD

2023-09-18 Thread houxiaoyu

Hi dev,
   This thread is to start a vote for PIP-301: Introduce
LoadBalanceResources to unify the load-date CRUD

   Discuss thread :
https://lists.apache.org/thread/7ngw9dc62tj2c4c5484dgsnlwgtstpbj
   PIP: https://github.com/apache/pulsar/pull/21129



Regards
houxiaoyu

[DISCUSS] PIP-301: Introduce LoadBalanceResources to unify the load-date CRUD

2023-09-05 Thread houxiaoyu

Hi Pulsar Community,

This is the discussion thread for PIP
https://github.com/apache/pulsar/pull/21129.

This PIP is going to refactor the code and introduce LoadBalanceResources
to unify the load-date CRUD

Thanks,
houxiaoyu

Re: [VOTE] Accept pulsar-admin-go as part of the Apache Pulsar project

2023-08-07 Thread houxiaoyu

Great!

+1 non-binding

Thanks,
Xiaoyu Hou

Cong Zhao  于2023年8月7日周一 19:18写道：

> Great!
>
> +1 non-binding
>
> Thanks,
> Cong Zhao
>
> On 2023/08/05 04:14:24 tison wrote:
> > Hi,
> >
> > I'd like to start a vote thread for accepting pulsar-admin-go[1] as part
> of
> > the Apache Pulsar project. pulsar-admin-go is a Golang client library
> > interacting with Pulsar Admin API. You can see the full proposal,
> including
> > the motivation and features at [2].
> >
> > Please vote with your opinions. The VOTE will remain open for at least 72
> > hours.
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > Vote from PMC members is binding.
> >
> > Best,
> > tison.
> >
> > [1] https://github.com/streamnative/pulsar-admin-go
> > [2] https://lists.apache.org/thread/tb6c10qlkg9fj56qc0ldkwc79j7qm0vc
> >
>

Re: [DISCUSS] PIP-285: Add pulsar_subscription_back_log_duration metric

2023-07-24 Thread houxiaoyu

+1

Thanks
Xiaoyu Hou

丛搏  于2023年7月24日周一 19:58写道：

> Hi, Pulsar Community
>
> I opened a new PIP design PR.
>
> https://github.com/apache/pulsar/pull/20859
>
> Thanks,
> Bo
>

Re: [ANNOUNCE] Zili Chen (tison) as new PMC member in Apache Pulsar

2023-07-22 Thread houxiaoyu

Congrats, Tison!

Best,
Xiaoyu Hou

Dave Fisher  于2023年7月22日周六 22:23写道：

> Congratulations!
>
> Sent from my iPhone
>
> > On Jul 21, 2023, at 10:05 AM, Michael Marshall 
> wrote:
> >
> > Hi Pulsar Community,
> >
> > The Apache Pulsar Project Management Committee (PMC) has invited Zili
> Chen
> > (https://github.com/tisonkun) as a member of the PMC and we are
> > pleased to announce that tison has accepted.
> >
> > tison is very active in the community by contributing and reviewing
> > many PRs, actively engaging on the mailing list, triaging GitHub
> > Issues, and helping out with the website.
> >
> > On behalf of the Pulsar PMC, welcome and congratulations to tison!
> >
> > Best,
> > Michael
>

Re: [VOTE] PIP-279: Reformat property in generateResponseWithEntry

2023-06-27 Thread houxiaoyu

+1 (non-binding)

Xiaoyu Hou

steven lu  于2023年6月28日周三 09:40写道：

> Hi, community:
>
> # Motivation
>
> reformat property,for a http header name cannot contain the following
> prohibited characters: =,;: \t\r\n\v\f
>
> for example:
> {"city=shanghai":"tag"}
> when we run `bin/pulsar-admin topics get-message-by-id `, it will
> throw exception, the exception is:
> `Reason: java.util.concurrent.CompletionException:
>
> org.apache.pulsar.client.admin.internal.http.AsyncHttpConnector$RetryException:
> Could not complete the operation. Number of retries has been
> exhausted. Failed reason: a header name cannot contain the following
> prohibited characters: =,;: \t\r\n\v\f: =`
>
> # High Level Design
>
> In master branch,
> in an http
> request:getMessageById("/{tenant}/{namespace}/{topic}/ledger/{ledgerId}/entry/{entryId}"),
> replace `"X-Pulsar-PROPERTY-" + msgProperties.getKey()` with
> `"X-Pulsar-PROPERTY"`
>
> After release-3.1.0, this feature begins to take effect.
>
>
> PIP: https://github.com/apache/pulsar/pull/20627
>
> PR: https://github.com/apache/pulsar/pull/20481
>

Re: [DISCUSS] PIP-279: Reformat property in generateResponseWithEntry

2023-06-26 Thread houxiaoyu

+1 non-binding

Xiaoyu Hou

Enrico Olivelli  于2023年6月26日周一 14:57写道：

> +1 (binding)
>
> Enrico
>
> Il giorno lun 26 giu 2023 alle ore 07:53 guo jiwei
>  ha scritto:
> >
> > +1 (binding)
> >
> > This is a bug and we need this fix.
> >
> >
> >
> >
> > Regards
> > Jiwei Guo (Tboy)
> >
> >
> > On Wed, Jun 21, 2023 at 11:23 AM steven lu 
> wrote:
> >
> > > # Motivation
> > >
> > > reformat property,for a http header name cannot contain the following
> > > prohibited characters: =,;: \t\r\n\v\f
> > >
> > > for example:
> > > {"city=shanghai":"tag"}
> > > when we run `bin/pulsar-admin topics get-message-by-id `, it will
> > > throw exception, the exception is:
> > > `Reason: java.util.concurrent.CompletionException:
> > >
> > >
> org.apache.pulsar.client.admin.internal.http.AsyncHttpConnector$RetryException:
> > > Could not complete the operation. Number of retries has been
> > > exhausted. Failed reason: a header name cannot contain the following
> > > prohibited characters: =,;: \t\r\n\v\f: =`
> > >
> > >  > > src="
> > >
> https://github.com/StevenLuMT/pulsar/assets/42990025/973d95b9-4ac2-4977-b160-162c4b53a613
> > > ">
> > >
> > > # High Level Design
> > >
> > > In master branch,
> > > in an http
> > >
> request:getMessageById("/{tenant}/{namespace}/{topic}/ledger/{ledgerId}/entry/{entryId}"),
> > > replace `"X-Pulsar-PROPERTY-" + msgProperties.getKey()` with
> > > `"X-Pulsar-PROPERTY"`
> > >
> > > After release-3.1.0, this feature begins to take effect.
> > >
>

Re: [VOTE] PIP-275: Introduce topicOrderedExecutorThreadNum to deprecate numWorkerThreadsForNonPersistentTopic in configuration

2023-06-20 Thread houxiaoyu

Close this vote by

4 binding +1s
* bogong
* Enrico
* Jiwei Guo (Tboy)
* Haiting


1 non-binding +1s
* Asaf Mesika

Thanks all,
Xiaoyu Hou

Haiting Jiang  于2023年6月20日周二 15:48写道：

> +1 binding
>
> Thanks,
> Haiting
>
> On Tue, Jun 20, 2023 at 2:02 PM guo jiwei  wrote:
> >
> > +1 (binding)
> >
> >
> > Regards
> > Jiwei Guo (Tboy)
> >
> >
> > On Mon, Jun 19, 2023 at 9:00 PM Enrico Olivelli 
> wrote:
> >
> > > +1 (binding)
> > >
> > > Enrico
> > >
> > > Il giorno lun 19 giu 2023 alle ore 14:48 Asaf Mesika
> > >  ha scritto:
> > > >
> > > > +1 (non binding)
> > > >
> > > > On Mon, Jun 19, 2023 at 9:19 AM 丛搏  wrote:
> > > >
> > > > > +1(binding)
> > > > >
> > > > > Thanks,
> > > > > Bo
> > > > >
> > > > > houxiaoyu  于2023年6月19日周一 14:04写道：
> > > > > >
> > > > > > Hi, community:
> > > > > >
> > > > > > This thread is to start a vote for PIP-275: Introduce
> > > > > > topicOrderedExecutorThreadNum to deprecate
> > > > > > numWorkerThreadsForNonPersistentTopic in configuration.
> > > > > >
> > > > > > Discussion thread:
> > > > > > https://lists.apache.org/thread/hx8v824v5wdoz3kn44s4t9pzgfnqkt1o
> > > > > > PIP-PR: https://github.com/apache/pulsar/pull/20507
> > > > > >
> > > > > > Sincerely
> > > > > > Xiaoyu Hou
> > > > >
> > >
>

[VOTE] PIP-275: Introduce topicOrderedExecutorThreadNum to deprecate numWorkerThreadsForNonPersistentTopic in configuration

2023-06-19 Thread houxiaoyu

Hi, community:

This thread is to start a vote for PIP-275: Introduce
topicOrderedExecutorThreadNum to deprecate
numWorkerThreadsForNonPersistentTopic in configuration.

Discussion thread:
https://lists.apache.org/thread/hx8v824v5wdoz3kn44s4t9pzgfnqkt1o
PIP-PR: https://github.com/apache/pulsar/pull/20507

Sincerely
Xiaoyu Hou

Re: [DISCUSS] PIP-275: Introduce numWorkerThreadsForPersistentTopic to deprecate numWorkerThreadsForNonPersistentTopic in configuration

2023-06-13 Thread houxiaoyu

Updated the new Introduced name as `topicOrderedExecutorThreadNum`.

Is there any other suggestions? Or I will start the VOTE later. :)

Thanks
Xiaoyu Hou

houxiaoyu  于2023年6月8日周四 13:07写道：

> Hi Enrico
>
> `numWorkersTopicOrderedExecutor` is OK. I have updated the pip
>
> Thanks,
> Xiaoyu Hou
>
> Enrico Olivelli  于2023年6月7日周三 15:44写道：
>
>> I would call it numWorkersTopicOrderedExecutor and remove
>> "persistent/non-persistent" from the name.
>>
>> Or alternatively we could introduce a topicOrderedExecutor for
>> persistent topics.
>>
>> Unfortunately the topicOrderedExecutor is now used for many things (I
>> also used it the wrong way when I introduced some features, sorry
>> about that).
>> Initially it was meant only for non-persistent topics, but now it is
>> used for anything that needs to be done under strict order for a
>> topic, like processing Subscriptions even for a persistent topic.
>>
>> Enrico
>>
>> Il giorno mer 7 giu 2023 alle ore 07:28 houxiaoyu
>>  ha scritto:
>> >
>> > Hi Rajan,
>> > Thanks for your reply.
>> >
>> > The `numWorkerThreadsForNonPersistentTopic` will specify the thread num
>> of
>> > `BrokerService#topicOrderedExecutor` [0].
>> > However, the `topicOrderedExecutor` are both used for `persistent` and
>> > `non-persistent` topics, not just for `non-persistent`:
>> > * There is only one place invoke `topicOrderedExecutor` for
>> > `non-persistent` topics. [1]
>> > * Other places will invoke `topicOrderedExecutor` for `persistent`
>> topic,
>> > e.g., [2][3][4][5]
>> >
>> > In short, `numWorkerThreadsForNonPersistentTopic` is not the `Number of
>> > worker threads to serve non-persistent topic` only.  So how about change
>> > the name to `numWorkerThreadsTopic`
>> >
>> >
>> > [0]
>> >
>> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/BrokerService.java#L317C14-L320
>> > [1]
>> >
>> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/ServerCnx.java#L1705-L1709
>> > [2]
>> >
>> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherMultipleConsumers.java#L134-L142
>> > [3]
>> >
>> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentTopic.java#L279-L281
>> > [4]
>> >
>> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherSingleActiveConsumer.java#L77-L83
>> > [5]
>> >
>> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentStickyKeyDispatcherMultipleConsumers.java#L392-L396
>> >
>> > Thanks
>> >
>> >
>> >
>> >
>> > Rajan Dhabalia  于2023年6月6日周二 14:57写道：
>> >
>> > > Hi,
>> > >
>> > > We already have a default number of threads for persistent topics but
>> we
>> > > have added a feature non-persistent topics and to isolate that path we
>> > > introduced a number of worker threads which we can reduce or tune
>> based on
>> > > resources we would like to allocate for non-persistent topics. So, it
>> > > really doesn't make sense and I don't see any clear reason in this
>> PIP why
>> > > we would like to take away control to tune thread resources to
>> > > non-persistent topics.
>> > >
>> > > Thanks,
>> > > Rajan
>> > >
>> > > On Mon, Jun 5, 2023 at 10:56 PM houxiaoyu 
>> wrote:
>> > >
>> > > > Hi Pulsar Community,
>> > > >
>> > > > I am writing to start the discussion on PIP-275: Introduce
>> > > > numWorkerThreadsForPersistentTopic to deprecate
>> > > > numWorkerThreadsForNonPersistentTopic in configuration
>> > > >
>> > > > PR with PIP contents: https://github.com/apache/pulsar/pull/20507
>> > > >
>> > > > # Motivation
>> > > >
>> > > > Introduce `numWorkerThreadsForPersistentTopic` to deprecate
>> > > > `numWorkerThreadsForNonPersistentTopic`.
>> > > >
>> > > > The `numWorkerThreadsForNonPersistentTopic` is used to specify for
>> > > > PersistentTopic, not NonPersistentTopic. So I propose change the
>> config
>> > > > item from `numWorkerThreadsForNonPersistentTopic` to
>> > > > `numWorkerThreadsForPersistentTopic`:
>> > > >
>> > > > Thanks,
>> > > > Xiaoyu Hou
>> > > >
>> > >
>>
>

Re: [DISCUSS] PIP-275: Introduce numWorkerThreadsForPersistentTopic to deprecate numWorkerThreadsForNonPersistentTopic in configuration

2023-06-07 Thread houxiaoyu

Hi Enrico

`numWorkersTopicOrderedExecutor` is OK. I have updated the pip

Thanks,
Xiaoyu Hou

Enrico Olivelli  于2023年6月7日周三 15:44写道：

> I would call it numWorkersTopicOrderedExecutor and remove
> "persistent/non-persistent" from the name.
>
> Or alternatively we could introduce a topicOrderedExecutor for
> persistent topics.
>
> Unfortunately the topicOrderedExecutor is now used for many things (I
> also used it the wrong way when I introduced some features, sorry
> about that).
> Initially it was meant only for non-persistent topics, but now it is
> used for anything that needs to be done under strict order for a
> topic, like processing Subscriptions even for a persistent topic.
>
> Enrico
>
> Il giorno mer 7 giu 2023 alle ore 07:28 houxiaoyu
>  ha scritto:
> >
> > Hi Rajan,
> > Thanks for your reply.
> >
> > The `numWorkerThreadsForNonPersistentTopic` will specify the thread num
> of
> > `BrokerService#topicOrderedExecutor` [0].
> > However, the `topicOrderedExecutor` are both used for `persistent` and
> > `non-persistent` topics, not just for `non-persistent`:
> > * There is only one place invoke `topicOrderedExecutor` for
> > `non-persistent` topics. [1]
> > * Other places will invoke `topicOrderedExecutor` for `persistent` topic,
> > e.g., [2][3][4][5]
> >
> > In short, `numWorkerThreadsForNonPersistentTopic` is not the `Number of
> > worker threads to serve non-persistent topic` only.  So how about change
> > the name to `numWorkerThreadsTopic`
> >
> >
> > [0]
> >
> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/BrokerService.java#L317C14-L320
> > [1]
> >
> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/ServerCnx.java#L1705-L1709
> > [2]
> >
> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherMultipleConsumers.java#L134-L142
> > [3]
> >
> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentTopic.java#L279-L281
> > [4]
> >
> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherSingleActiveConsumer.java#L77-L83
> > [5]
> >
> https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentStickyKeyDispatcherMultipleConsumers.java#L392-L396
> >
> > Thanks
> >
> >
> >
> >
> > Rajan Dhabalia  于2023年6月6日周二 14:57写道：
> >
> > > Hi,
> > >
> > > We already have a default number of threads for persistent topics but
> we
> > > have added a feature non-persistent topics and to isolate that path we
> > > introduced a number of worker threads which we can reduce or tune
> based on
> > > resources we would like to allocate for non-persistent topics. So, it
> > > really doesn't make sense and I don't see any clear reason in this PIP
> why
> > > we would like to take away control to tune thread resources to
> > > non-persistent topics.
> > >
> > > Thanks,
> > > Rajan
> > >
> > > On Mon, Jun 5, 2023 at 10:56 PM houxiaoyu  wrote:
> > >
> > > > Hi Pulsar Community,
> > > >
> > > > I am writing to start the discussion on PIP-275: Introduce
> > > > numWorkerThreadsForPersistentTopic to deprecate
> > > > numWorkerThreadsForNonPersistentTopic in configuration
> > > >
> > > > PR with PIP contents: https://github.com/apache/pulsar/pull/20507
> > > >
> > > > # Motivation
> > > >
> > > > Introduce `numWorkerThreadsForPersistentTopic` to deprecate
> > > > `numWorkerThreadsForNonPersistentTopic`.
> > > >
> > > > The `numWorkerThreadsForNonPersistentTopic` is used to specify for
> > > > PersistentTopic, not NonPersistentTopic. So I propose change the
> config
> > > > item from `numWorkerThreadsForNonPersistentTopic` to
> > > > `numWorkerThreadsForPersistentTopic`:
> > > >
> > > > Thanks,
> > > > Xiaoyu Hou
> > > >
> > >
>

Re: [DISCUSS] PIP-275: Introduce numWorkerThreadsForPersistentTopic to deprecate numWorkerThreadsForNonPersistentTopic in configuration

2023-06-06 Thread houxiaoyu

Hi Rajan,
Thanks for your reply.

The `numWorkerThreadsForNonPersistentTopic` will specify the thread num of
`BrokerService#topicOrderedExecutor` [0].
However, the `topicOrderedExecutor` are both used for `persistent` and
`non-persistent` topics, not just for `non-persistent`:
* There is only one place invoke `topicOrderedExecutor` for
`non-persistent` topics. [1]
* Other places will invoke `topicOrderedExecutor` for `persistent` topic,
e.g., [2][3][4][5]

In short, `numWorkerThreadsForNonPersistentTopic` is not the `Number of
worker threads to serve non-persistent topic` only.  So how about change
the name to `numWorkerThreadsTopic`


[0]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/BrokerService.java#L317C14-L320
[1]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/ServerCnx.java#L1705-L1709
[2]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherMultipleConsumers.java#L134-L142
[3]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentTopic.java#L279-L281
[4]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherSingleActiveConsumer.java#L77-L83
[5]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentStickyKeyDispatcherMultipleConsumers.java#L392-L396

Thanks




Rajan Dhabalia  于2023年6月6日周二 14:57写道：

> Hi,
>
> We already have a default number of threads for persistent topics but we
> have added a feature non-persistent topics and to isolate that path we
> introduced a number of worker threads which we can reduce or tune based on
> resources we would like to allocate for non-persistent topics. So, it
> really doesn't make sense and I don't see any clear reason in this PIP why
> we would like to take away control to tune thread resources to
> non-persistent topics.
>
> Thanks,
> Rajan
>
> On Mon, Jun 5, 2023 at 10:56 PM houxiaoyu  wrote:
>
> > Hi Pulsar Community,
> >
> > I am writing to start the discussion on PIP-275: Introduce
> > numWorkerThreadsForPersistentTopic to deprecate
> > numWorkerThreadsForNonPersistentTopic in configuration
> >
> > PR with PIP contents: https://github.com/apache/pulsar/pull/20507
> >
> > # Motivation
> >
> > Introduce `numWorkerThreadsForPersistentTopic` to deprecate
> > `numWorkerThreadsForNonPersistentTopic`.
> >
> > The `numWorkerThreadsForNonPersistentTopic` is used to specify for
> > PersistentTopic, not NonPersistentTopic. So I propose change the config
> > item from `numWorkerThreadsForNonPersistentTopic` to
> > `numWorkerThreadsForPersistentTopic`:
> >
> > Thanks,
> > Xiaoyu Hou
> >
>

[DISCUSS] PIP-275: Introduce numWorkerThreadsForPersistentTopic to deprecate numWorkerThreadsForNonPersistentTopic in configuration

2023-06-05 Thread houxiaoyu

Hi Pulsar Community,

I am writing to start the discussion on PIP-275: Introduce
numWorkerThreadsForPersistentTopic to deprecate
numWorkerThreadsForNonPersistentTopic in configuration

PR with PIP contents: https://github.com/apache/pulsar/pull/20507

# Motivation

Introduce `numWorkerThreadsForPersistentTopic` to deprecate
`numWorkerThreadsForNonPersistentTopic`.

The `numWorkerThreadsForNonPersistentTopic` is used to specify for
PersistentTopic, not NonPersistentTopic. So I propose change the config
item from `numWorkerThreadsForNonPersistentTopic` to
`numWorkerThreadsForPersistentTopic`:

Thanks,
Xiaoyu Hou

Re: [DISCUSS] We must change the way we review PIPs

2023-03-30 Thread houxiaoyu

Big +1(non-binding) to me

Thanks,
Hou Xiaoyu

Yunze Xu  于2023年3月31日周五 10:45写道：

> +1 to me. Once the discussion thread of a PIP became too long, it
> would be hard to continue the discussion.
>
> Thanks,
> Yunze
>
> On Fri, Mar 31, 2023 at 9:13 AM PengHui Li  wrote:
> >
> > +1 for creating a folder named "pip" in the main pulsar repo
> > So far, it is good enough to solve the problems we've had.
> >
> > If it is really worth moving to another repo in the future.
> > We can move it maybe 3, 5 years later.
> >
> > Thanks,
> > Penghui
> >
> >
> > On Fri, Mar 31, 2023 at 8:29 AM tison  wrote:
> >
> > > Hi Asaf,
> > >
> > > Thanks for starting this thread!
> > >
> > > I have similar thoughts on using a single source for reviewing PIPs.
> GH PRs
> > > are good for conversation, although multiple conversations are still
> hard
> > > to follow (which can be natural)
> > >
> > > Here is how Rust does it[1] - a self-documented RFC repo + review PRs +
> > > tracking issue on the main repo once accepted.
> > >
> > > Here is what I designed for TiDB[2][3]; proposals are placed in a
> folder
> > > under the main repo.
> > >
> > > We don't have to follow other community's ways, but these two practices
> > > seem good to read.
> > >
> > > And, to follow the ASF voting strategy[4][5], we may still need a
> standard
> > > vote mail thread and document the result on the mailing list.
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://github.com/rust-lang/rfcs
> > > [2] https://github.com/pingcap/tidb/tree/master/docs/design
> > > [3]
> > >
> > >
> https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html
> > > [4] https://www.apache.org/foundation/voting.html
> > > [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy
> > >
> > >
> > > Girish Sharma  于2023年3月31日周五 04:33写道：
> > >
> > > > +1 (non-binding .. ? )
> > > > I've already commented a couple of times (here and there) that the
> > > process
> > > > needs to be consolidated at a single place. This is a good and
> detailed
> > > > approach.
> > > > Not sure if there is a historical context behind keeping the
> discussion
> > > in
> > > > dev mailing list..
> > > >
> > > > Regards
> > > >
> > > > On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika 
> > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > In the last 2 months, I've increased my PIP review time (I do it in
> > > > > cycles), and reviewed quite a few PIPs.
> > > > >
> > > > > My conclusion as a result of that:
> > > > >
> > > > > It's nearly impossible to review PIPs using a mailing list.
> > > > > We must fix it soon.
> > > > >
> > > > > *Why?*
> > > > > 1. Let's say you review the PIP and find 10 issues. Once you quote
> and
> > > > > comment on those ten points, you basically started 10 threads of
> > > > > conversations.
> > > > > After 2-3 ping pongs with quotes of quotes of quotes, it takes you
> > > > forever
> > > > > to read each thread properly. You find your CTRL-F to search to
> find
> > > your
> > > > > original quote, and reply. Load it up again in your head,
> switching to
> > > > the
> > > > > PIP tab to read it again.
> > > > > After 10 ping pongs, it becomes almost an impossible mission.
> > > > >
> > > > > I can say I'm 75% tired just from the process, not from the review
> > > > itself.
> > > > >
> > > > > 2. It's non collaborative by design.
> > > > > After 10 ping pongs, the ability of someone to come and join the
> > > > discussion
> > > > > is 0. They need to go through so many replies, which are half
> quotes,
> > > > find
> > > > > the original reply, and browse to the PIP.
> > > > > It's no wonder people drop off the PIP review once we cross 5-6
> > > replies.
> > > > > It's no wonder, nobody joins after 10 replies.
> > > > >
> > > > > 3. It's not open to the public. Non collaborative.
> > > > > You can't just get a link, and join the review. Not only because
> of (1)
> > > > and
> > > > > (2). You need to join the mailing list. You don't get the past
> emails
> > > to
> > > > > reply. Just joining the list is a high enough bar for many people.
> > > > > I personally participated in review of proposals in OpenTelemetry
> in
> > > the
> > > > > last 6 months, even though I'm just an occasional user.  Why? They
> were
> > > > > conducted on GitHub PR , so it was easy for me - click a link and
> > > reply.
> > > > >
> > > > > 4. All over the place
> > > > > Sometimes people comment on the GitHub issue.
> > > > > Sometimes on the mailing list.
> > > > > Not a single place.
> > > > >
> > > > > 5. No history.
> > > > > Ok, finally the author was convinced. I can't see just the changes.
> > > They
> > > > > need to explicitly tell me something was changed.
> > > > >
> > > > > 6. Delete All.
> > > > > They can go crazy, after 1 year, edit the GitHub issue , delete
> all the
> > > > > text and write "Kafka is the king". No history, nobody can stop
> them.
> > > > It's
> > > > > their issue.
> > > > >
> > > > > 7. Show me all the approved PIPs
> > > > >

Re: [ANNOUNCE] Qiang Zhao as new PMC member in Apache Pulsar

2023-03-29 Thread houxiaoyu

Congratulations !

Hou Xiaoyu

Enrico Olivelli  于2023年3月29日周三 15:03写道：

> Congratulations !
>
> Well deserved !
>
> Enrico
>
> Il giorno mer 29 mar 2023 alle ore 06:17 Xiangying Meng
>  ha scritto:
> >
> >  Congrats! Qiang.
> >
> > Sincerely,
> > Xiangying
> >
> > On Wed, Mar 29, 2023 at 11:51 AM Yubiao Feng
> >  wrote:
> >
> > > Congrats! Qiang.
> > >
> > > Thanks
> > > Yubiao
> > >
> > > On Wed, Mar 29, 2023 at 11:22 AM guo jiwei 
> wrote:
> > >
> > > > Dear Community,
> > > >
> > > > We are thrilled to announce that Qiang Zhao
> > > > (https://github.com/mattisonchao) has been invited and has accepted
> the
> > > > role of member of the Apache Pulsar Project Management Committee
> (PMC).
> > > >
> > > > Qiang has been a vital asset to our community, consistently
> > > > demonstrating his dedication and active participation through
> > > > significant contributions. In addition to his technical
> contributions,
> > > > Qiang also plays an important role in reviewing pull requests and
> > > > ensuring the overall quality of our project. We look forward to his
> > > > continued contributions.
> > > >
> > > > On behalf of the Pulsar PMC, we extend a warm welcome and
> > > > congratulations to Qiang Zhao.
> > > >
> > > > Best regards
> > > > Jiwei
> > > >
> > >
>

Re: [DISCUSS] PIP-247: Notifications for partitions update

2023-03-20 Thread houxiaoyu

Hi all

Is there any other comments about this design :)

Thanks,
Xiaoyu Hou

houxiaoyu  于2023年3月8日周三 16:22写道：

> Hi Michael,
>
> > is there a reason that we couldn't also use this to improve PIP 145?
>
> The protocol described in this PIP could also be used to improve PIP-145.
> However I think that it' not a good reason that we use  the regex sub
> watcher to implement the partitioned update watcher because of the other
> reasons we mentioned above.
>
> > Since we know we're using a TCP connection, is it possible to rely on
> > pulsar's keep alive timeout (the broker and the client each have their
> > own) to close a connection that isn't responsive?
>
> Maybe it could fail on application layer I think,  for example, the
> partitioned update listener run fail unexceptionly.  Currently another task
> will be scheduled if the poll task encounters error in partition auto
> update timer task. [0]
>
> > Regarding the connection, which connection should the client use to send
> the watch requests?
>
> The `PartitionUpdateWatcher` will call `connectionHandler.grabCnx()` to
> open an connection, which is analogous to `TopicListWatcher`. [1]
>
> > do we plan on using metadata storenotifications to trigger the callbacks
> that trigger notifications sent
> > to the clients
>
> Yes, we will just look up the metadataStore to fetch the count of the
> partitions and register a watcher to the metadataStore to trigger the count
> update.
>
> > One nit on the protobuf for CommandWatchPartitionUpdateSuccess:
> >
> >repeated string topics = 3;
> >   repeated uint32 partitions = 4;
> >
> > What do you think about using a repeated message that represents a
> > pair of a topic and its partition count instead of using two lists?
>
> Great. It looks better using a repeated message, I will update the
> protobuf.
>
> > How will we handle the case where a watched topic does not exist?
>
> 1. When `PulsarClient` calls `create()` to create a producer or  calls
> `subscribe()` to create a consumer,  the client will first get
> partitioned-topic metadata from broker, [2]. If the topic doesn't exist and
> `isAllowAutoTopicCreation=true` in broker, the partitioned-topic zk node
> will auto create with default partition num.
> 2.  After the client getting partitioned-topic metadata successfully,  the
> `PartitionedProducerImpl` will be create if `meta.partition >
> 0`.  `PartitionUpdateWatcher` will be initilized in
> `PartitionedProducerImpl` constructor. The `PartitionUpdateWatcher` sends
> command to broker to register a watcher. If any topic in the topicList
> doesn't exist,  the broker will send error to the client and the
> `PartitionedProducerImpl` will start fail.  `MultiTopicsConsumerImpl` will
> work in the same way.
>
> > I want to touch on authorization. A role should have "lookup"
> > permission to watch for updates on each partitioned topic that it
> > watches. As a result, if we allow for a request to watch multiple
> > topics, some might succeed while others fail. How do we handle partial
> > success?
>
> If any topic in the topicList authorizes fail, the broker will send error
> to the client. The following reasons support this action:
> 1. Before we sending command to register a partition update watcher, the
> client should have send the `CommandPartitionedTopicMetadata` and should
> have the `lookup` permission [3] [4].
> 2. Currently if any topic subsrbies fail the consumer wil start faiil. [5]
>
>
> [0]
> https://github.com/apache/pulsar/blob/af1360fb167c1f9484fda5771df3ea9b21d1440b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/MultiTopicsConsumerImpl.java#L1453-L1461
>
> [1]
> https://github.com/apache/pulsar/blob/af1360fb167c1f9484fda5771df3ea9b21d1440b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/TopicListWatcher.java#L67-L81
>
> [2]
> https://github.com/apache/pulsar/blob/af1360fb167c1f9484fda5771df3ea9b21d1440b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/PulsarClientImpl.java#L365-L371
>
> [3]
> https://github.com/apache/pulsar/blob/af1360fb167c1f9484fda5771df3ea9b21d1440b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/MultiTopicsConsumerImpl.java#L903-L923
>
> [4]
> https://github.com/apache/pulsar/blob/af1360fb167c1f9484fda5771df3ea9b21d1440b/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/ServerCnx.java#L558-L560
>
> [5]
> https://github.com/apache/pulsar/blob/af1360fb167c1f9484fda5771df3ea9b21d1440b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/MultiTopicsConsumerImpl.java#L171-L193
>
> Thanks,
> Xiaoyu Hou
>
> Michael Marshall  于2023年3月7日周二 15:43写道：
>
>> T

Re: [DISCUSS] PIP-247: Notifications for partitions update

2023-03-08 Thread houxiaoyu

 an ack mechanism to get around this. I
> haven't looked closely, but is there a reason that we couldn't also
> use this to improve PIP 145?
>
> Since we know we're using a TCP connection, is it possible to rely on
> pulsar's keep alive timeout (the broker and the client each have their
> own) to close a connection that isn't responsive? Then, when the
> connection is re-established, the client would get the latest topic
> partition count.
>
> Regarding the connection, which connection should the client use to
> send the watch requests? At the moment, the "parent" partitioned topic
> does not have an owner, but perhaps it would help this design to make
> a single owner for a given partitioned topic. This could trivially be
> done using the existing bundle mapping. Then, all watchers for a given
> partitioned topic would be hosted on the same broker, which should be
> more efficient. I don't think we currently redirect clients to any
> specific bundle when creating the metadata for a partitioned topic,
> but if we did, then we might be able to remove some edge cases for
> notification delivery because a single broker would update the
> metadata store and then trigger the notifications to the clients. If
> we don't use this implementation, do we plan on using metadata store
> notifications to trigger the callbacks that trigger notifications sent
> to the clients?
>
> > - Each time meta-update you'll need to run it through regular
> > expression, on all topics hosted on the broker, for any given client.
> > That's a lot of CPU.
> > - Suggested mechanism mainly cares about the count of partitions, so
> > it's a lot more efficient.
>
> I forgot the partition count was its own piece of metadata that the
> broker can watch for. That part definitely makes sense to me.
>
> One nit on the protobuf for CommandWatchPartitionUpdateSuccess:
>
> repeated string topics = 3;
> repeated uint32 partitions = 4;
>
> What do you think about using a repeated message that represents a
> pair of a topic and its partition count instead of using two lists?
>
> How will we handle the case where a watched topic does not exist?
>
> I want to touch on authorization. A role should have "lookup"
> permission to watch for updates on each partitioned topic that it
> watches. As a result, if we allow for a request to watch multiple
> topics, some might succeed while others fail. How do we handle partial
> success?
>
> One interesting detail is that this PIP is essentially aligned with
> notifying clients when topic metadata changes while PIP 145 was
> related to topic creation itself. An analogous proposal could request
> a notification for any topic that gets a new metadata label. I do not
> think it is worth considering that case in this design.
>
> Thanks,
> Michael
>
> [0] https://lists.apache.org/thread/t4cwht08d4mhp3qzoxmqh6tht8l0728r
>
> On Sun, Mar 5, 2023 at 8:01 PM houxiaoyu  wrote:
> >
> > Bump. Are there other concerns or suggestions about this PIP :)  Ping @
> > Michael @Joe @Enrico
> >
> > Thanks
> > Xiaoyu Hou
> >
> > houxiaoyu  于2023年2月27日周一 14:10写道：
> >
> > > Hi Joe and Michael,
> > >
> > > I think I misunderstood what you replied before. Now I understand and
> > > explain it again.
> > >
> > > Besides the reasons what Asaf mentioned above, there are also some
> limits
> > > for using topic list watcher.  For example the `topicsPattern.pattern`
> must
> > > less that `maxSubscriptionPatternLeng` [0]. If the consumer subscribes
> > > multi partitioned-topics, the `topicsPattern.pattern` maybe very long.
> > >
> > > So I think that it's better to have a separate notification
> implementation
> > > for partition update.
> > >
> > > [0]
> > >
> https://github.com/apache/pulsar/blob/5d6932137d76d544f939bef27df25f61b4a4d00d/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/TopicListService.java#L115-L126
> > >
> > > Thanks,
> > > Xiaoyu Hou
> > >
> > > houxiaoyu  于2023年2月27日周一 10:56写道：
> > >
> > >> Hi Michael,
> > >>
> > >> >  I think we just need the client to "subscribe" to a topic
> notification
> > >> for
> > >> >  "-partition-[0-9]+" to eliminate the polling
> > >>
> > >> If pulsar users want to pub/sub a partitioned-topic, I think most of
> the
> > >> users would like to create a simple producer or consumer like
> following:
> > >> ```
> > >> Producer producer =
> client.newProducer().top

Re: [VOTE]PIP-247: Notifications for partitions update.

2023-03-05 Thread houxiaoyu

Thanks Asaf,  I will continue the discussion on the discussion thread

Asaf Mesika  于2023年3月5日周日 21:16写道：

> +1with note: I think the discussion thread has not reached consensus.
>
>
> On Thu, Mar 2, 2023 at 1:21 PM houxiaoyu  wrote:
>
> > Dear Community,
> >
> > I would like to start a VOTE on "PIP-247: Notifications for partitions
> > update."
> >
> > The proposal can be read at [0] and the discussion thread is available at
> > [1]
> >
> > Voting will stay open for at least 48h.
> >
> > [0] https://github.com/apache/pulsar/issues/19596
> > [1] https://lists.apache.org/thread/bcry0cz4z7kzot8pc4nhbktfv44xrk2y
> >
> > Thanks,
> > Xiaoyu Hou
> >
>

Re: [DISCUSS] PIP-247: Notifications for partitions update

2023-03-05 Thread houxiaoyu

Bump. Are there other concerns or suggestions about this PIP :)  Ping @
Michael @Joe @Enrico

Thanks
Xiaoyu Hou

houxiaoyu  于2023年2月27日周一 14:10写道：

> Hi Joe and Michael,
>
> I think I misunderstood what you replied before. Now I understand and
> explain it again.
>
> Besides the reasons what Asaf mentioned above, there are also some limits
> for using topic list watcher.  For example the `topicsPattern.pattern` must
> less that `maxSubscriptionPatternLeng` [0]. If the consumer subscribes
> multi partitioned-topics, the `topicsPattern.pattern` maybe very long.
>
> So I think that it's better to have a separate notification implementation
> for partition update.
>
> [0]
> https://github.com/apache/pulsar/blob/5d6932137d76d544f939bef27df25f61b4a4d00d/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/TopicListService.java#L115-L126
>
> Thanks,
> Xiaoyu Hou
>
> houxiaoyu  于2023年2月27日周一 10:56写道：
>
>> Hi Michael,
>>
>> >  I think we just need the client to "subscribe" to a topic notification
>> for
>> >  "-partition-[0-9]+" to eliminate the polling
>>
>> If pulsar users want to pub/sub a partitioned-topic, I think most of the
>> users would like to create a simple producer or consumer like following:
>> ```
>> Producer producer = client.newProducer().topic(topic).create();
>> producer.sendAsync(msg);
>> ```
>> ```
>> client.newConsumer()
>> .topic(topic)
>> .subscriptionName(subscription)
>> .subscribe();
>> ```
>> I think there is no reason for users to use `topicsPattern` if a pulsar
>> just wants to subscribe a partitioned-topic. In addition, `topicsPattern`
>> couldn't be used for producers.
>>
>> So I think PIP-145 [0] will benefit for regex subscriptions.  And this
>> PIP [1] will benefit for the common partitioned-topic pub/sub scenario.
>>
>> [0] https://github.com/apache/pulsar/issues/14505
>> [1] https://github.com/apache/pulsar/issues/19596
>>
>> Thanks
>> Xiaoyu Hou
>>
>> Michael Marshall  于2023年2月25日周六 01:29写道：
>>
>>> > Just the way to implements partitioned-topic metadata
>>> > notification mechanism is much like notifications on regex sub changes
>>>
>>> Why do we need a separate notification implementation? The regex
>>> subscription feature is about discovering topics (not subscriptions)
>>> that match a regular expression. As Joe mentioned, I think we just
>>> need the client to "subscribe" to a topic notification for
>>> "-partition-[0-9]+" to eliminate the polling.
>>>
>>> Building on PIP 145, the work for this PIP would be in implementing a
>>> different `TopicsChangedListener` [1] so that the result of an added
>>> topic is to add a producer/consumer to the new partition.
>>>
>>> I support removing polling in our streaming platform, but I'd prefer
>>> to limit the number of notification systems we implement.
>>>
>>> Thanks,
>>> Michael
>>>
>>> [0] https://github.com/apache/pulsar/pull/16062
>>> [1]
>>> https://github.com/apache/pulsar/blob/82237d3684fe506bcb6426b3b23f413422e6e4fb/pulsar-client/src/main/java/org/apache/pulsar/client/impl/PatternMultiTopicsConsumerImpl.java#L169-L175
>>>
>>>
>>>
>>> On Fri, Feb 24, 2023 at 1:57 AM houxiaoyu  wrote:
>>> >
>>> > Hi Joe,
>>> >
>>> > When we use PartitionedProducerImpl or MultiTopicsConsumerImpl,  there
>>> is a
>>> > poll task to fetch the metadata of the partitioned-topic regularly for
>>> the
>>> > number of partitions updated.  This PIP wants to use a
>>> > notification mechanism to replace the metadata poll task.
>>> >
>>> > Just the way to implements partitioned-topic metadata
>>> > notification mechanism is much like notifications on regex sub changes
>>> >
>>> > Joe F  于2023年2月24日周五 13:37写道：
>>> >
>>> > > Why is this needed when we have notifications on regex sub changes?
>>> Aren't
>>> > > the partition names a well-defined regex?
>>> > >
>>> > > Joe
>>> > >
>>> > > On Thu, Feb 23, 2023 at 8:52 PM houxiaoyu 
>>> wrote:
>>> > >
>>> > > > Hi Asaf,
>>> > > > thanks for your reminder.
>>> > > >
>>> > > > ## Changing
>>> > > > I have updated the following changes to mak

[VOTE]PIP-247: Notifications for partitions update.

2023-03-02 Thread houxiaoyu

Dear Community,

I would like to start a VOTE on "PIP-247: Notifications for partitions
update."

The proposal can be read at [0] and the discussion thread is available at
[1]

Voting will stay open for at least 48h.

[0] https://github.com/apache/pulsar/issues/19596
[1] https://lists.apache.org/thread/bcry0cz4z7kzot8pc4nhbktfv44xrk2y

Thanks,
Xiaoyu Hou

Re: [ANNOUNCE] New committer: Yuri Mizushima

2023-02-27 Thread houxiaoyu

Congrats !

Yubiao Feng  于2023年2月28日周二 09:49写道：

> Congratulations!
> Thanks
> Yubiao Feng
>
> On Mon, Feb 27, 2023 at 3:47 PM Nozomi Kurihara 
> wrote:
>
> > Hi everyone,
> >
> > The Project Management Committee (PMC) for Apache Pulsar
> > has invited Yuri Mizushima (https://github.com/equanz) to become a
> > committer and we are pleased
> > to announce that he has accepted.
> >
> > Yuri has been an active contributor for over 3 years. He has constantly
> > sent Pull-Requests for Pulsar and its clients. Moreover he proposed
> PIP-79
> > and gave a talk at Pulsar Summit NA 2021.
> >
> > Please join us in congratulating and welcoming Yuri onboard!
> >
> > Thanks,
> > Nozomi
> >
>

Re: [DISCUSS] PIP-247: Notifications for partitions update

2023-02-26 Thread houxiaoyu

Hi Joe and Michael,

I think I misunderstood what you replied before. Now I understand and
explain it again.

Besides the reasons what Asaf mentioned above, there are also some limits
for using topic list watcher.  For example the `topicsPattern.pattern` must
less that `maxSubscriptionPatternLeng` [0]. If the consumer subscribes
multi partitioned-topics, the `topicsPattern.pattern` maybe very long.

So I think that it's better to have a separate notification implementation
for partition update.

[0]
https://github.com/apache/pulsar/blob/5d6932137d76d544f939bef27df25f61b4a4d00d/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/TopicListService.java#L115-L126

Thanks,
Xiaoyu Hou

houxiaoyu  于2023年2月27日周一 10:56写道：

> Hi Michael,
>
> >  I think we just need the client to "subscribe" to a topic notification
> for
> >  "-partition-[0-9]+" to eliminate the polling
>
> If pulsar users want to pub/sub a partitioned-topic, I think most of the
> users would like to create a simple producer or consumer like following:
> ```
> Producer producer = client.newProducer().topic(topic).create();
> producer.sendAsync(msg);
> ```
> ```
> client.newConsumer()
> .topic(topic)
> .subscriptionName(subscription)
> .subscribe();
> ```
> I think there is no reason for users to use `topicsPattern` if a pulsar
> just wants to subscribe a partitioned-topic. In addition, `topicsPattern`
> couldn't be used for producers.
>
> So I think PIP-145 [0] will benefit for regex subscriptions.  And this PIP
> [1] will benefit for the common partitioned-topic pub/sub scenario.
>
> [0] https://github.com/apache/pulsar/issues/14505
> [1] https://github.com/apache/pulsar/issues/19596
>
> Thanks
> Xiaoyu Hou
>
> Michael Marshall  于2023年2月25日周六 01:29写道：
>
>> > Just the way to implements partitioned-topic metadata
>> > notification mechanism is much like notifications on regex sub changes
>>
>> Why do we need a separate notification implementation? The regex
>> subscription feature is about discovering topics (not subscriptions)
>> that match a regular expression. As Joe mentioned, I think we just
>> need the client to "subscribe" to a topic notification for
>> "-partition-[0-9]+" to eliminate the polling.
>>
>> Building on PIP 145, the work for this PIP would be in implementing a
>> different `TopicsChangedListener` [1] so that the result of an added
>> topic is to add a producer/consumer to the new partition.
>>
>> I support removing polling in our streaming platform, but I'd prefer
>> to limit the number of notification systems we implement.
>>
>> Thanks,
>> Michael
>>
>> [0] https://github.com/apache/pulsar/pull/16062
>> [1]
>> https://github.com/apache/pulsar/blob/82237d3684fe506bcb6426b3b23f413422e6e4fb/pulsar-client/src/main/java/org/apache/pulsar/client/impl/PatternMultiTopicsConsumerImpl.java#L169-L175
>>
>>
>>
>> On Fri, Feb 24, 2023 at 1:57 AM houxiaoyu  wrote:
>> >
>> > Hi Joe,
>> >
>> > When we use PartitionedProducerImpl or MultiTopicsConsumerImpl,  there
>> is a
>> > poll task to fetch the metadata of the partitioned-topic regularly for
>> the
>> > number of partitions updated.  This PIP wants to use a
>> > notification mechanism to replace the metadata poll task.
>> >
>> > Just the way to implements partitioned-topic metadata
>> > notification mechanism is much like notifications on regex sub changes
>> >
>> > Joe F  于2023年2月24日周五 13:37写道：
>> >
>> > > Why is this needed when we have notifications on regex sub changes?
>> Aren't
>> > > the partition names a well-defined regex?
>> > >
>> > > Joe
>> > >
>> > > On Thu, Feb 23, 2023 at 8:52 PM houxiaoyu 
>> wrote:
>> > >
>> > > > Hi Asaf,
>> > > > thanks for your reminder.
>> > > >
>> > > > ## Changing
>> > > > I have updated the following changes to make sure the notification
>> > > arrived
>> > > > successfully:
>> > > > 1. The watch success response `CommandWatchPartitionUpdateSuccess`
>> will
>> > > > contain all the concerned topics of this watcher
>> > > > 2. The notification `CommandPartitionUpdate` will always contain
>> all the
>> > > > concerned topics of this watcher.
>> > > > 3. The notification `CommandPartitionUpdate`contains a monotonically
>> > > > increased version.
>> > > > 4. A map
>> `PartitonUp

Re: [DISCUSS] PIP-247: Notifications for partitions update

2023-02-26 Thread houxiaoyu

Hi Asaf,

>  Prefer something more explicit: onTopicPartitionsCountChanged
> Maybe we should mark "PartitionsChangedListener" deprecated?
> 60 seconds seems like *a lot* to miss an update. Maybe 5-10 sec

It looks good to me

> Let's think about the case of endless retries

We will remove the watcher from broker if `channelInactive` invoked like
PIP-145.  Endless retries should not happen if we do so I think.

> Can you elaborate on which broker you'll be doing that conversation with?
> Partitioned topic are spread across several brokers, so how can one broker
> know the count of the partitioned topic?

The client side  `PartitionUpdateWatcher` will extends `HandlerState`, It
could get connection to any broker services. The broker knows the count of
the partitioned topic throught metaDataStore, and it also could knows the
partitioned changed event from watching metaDataStore.

Thanks,
Xiaoyu Hou


Asaf Mesika  于2023年2月27日周一 00:31写道：

>  Michael,
>
> I think the current suggested protocol is more optimized compared to
> existing regex mechanism:
>
>- If the broker sends notification and it's lost due network issues,
>you'll only know about it due to the client doing constant polling,
> using
>its hash to minimize response.
>   - In the suggested mechanism, there's no constant polling at all.
>   Just think of introducing polling to *all* multiple partition
> producers and
>   consumers (Which likely all pulsar users). The suggested mechanism
> has a
>   configured timeout allowing it to resend on timeout, but only
> when it fails
>   as opposed to constant polling mechanisms.
>- Each time meta-update you'll need to run it through regular
>expression, on all topics hosted on the broker, for any given client.
>That's a lot of CPU.
>   - Suggested mechanism mainly cares about the count of partitions, so
>   it's a lot more efficient.
>
>
> Xiaoyu,
>
> I don't like the "onTopicExtend" method name. Prefer something more
> explicit: onTopicPartitionsCountChanged.
>
> Let's think about the case of endless retries - you know, the client is
> acting out, and never acknowledges. Need to to think about it.
> 60 seconds seems like *a lot* to miss an update. Maybe 5-10 sec?
>
> Can you elaborate on which broker you'll be doing that conversation with?
> Partitioned topic are spread across several brokers, so how can one broker
> know the count of the partitioned topic?
>
> Maybe we should mark "PartitionsChangedListener" deprecated? Having two
> interfaces is confusing.
>
>
>
> On Fri, Feb 24, 2023 at 7:29 PM Michael Marshall 
> wrote:
>
> > > Just the way to implements partitioned-topic metadata
> > > notification mechanism is much like notifications on regex sub changes
> >
> > Why do we need a separate notification implementation? The regex
> > subscription feature is about discovering topics (not subscriptions)
> > that match a regular expression. As Joe mentioned, I think we just
> > need the client to "subscribe" to a topic notification for
> > "-partition-[0-9]+" to eliminate the polling.
> >
> > Building on PIP 145, the work for this PIP would be in implementing a
> > different `TopicsChangedListener` [1] so that the result of an added
> > topic is to add a producer/consumer to the new partition.
> >
> > I support removing polling in our streaming platform, but I'd prefer
> > to limit the number of notification systems we implement.
> >
> > Thanks,
> > Michael
> >
> > [0] https://github.com/apache/pulsar/pull/16062
> > [1]
> >
> https://github.com/apache/pulsar/blob/82237d3684fe506bcb6426b3b23f413422e6e4fb/pulsar-client/src/main/java/org/apache/pulsar/client/impl/PatternMultiTopicsConsumerImpl.java#L169-L175
> >
> >
> >
> > On Fri, Feb 24, 2023 at 1:57 AM houxiaoyu  wrote:
> > >
> > > Hi Joe,
> > >
> > > When we use PartitionedProducerImpl or MultiTopicsConsumerImpl,  there
> > is a
> > > poll task to fetch the metadata of the partitioned-topic regularly for
> > the
> > > number of partitions updated.  This PIP wants to use a
> > > notification mechanism to replace the metadata poll task.
> > >
> > > Just the way to implements partitioned-topic metadata
> > > notification mechanism is much like notifications on regex sub changes
> > >
> > > Joe F  于2023年2月24日周五 13:37写道：
> > >
> > > > Why is this needed when we have notifications on regex sub changes?
> > Aren't
> > > > the partition names a well-defined regex?
> > > >
> >

Re: [DISCUSS] PIP-247: Notifications for partitions update

2023-02-26 Thread houxiaoyu

Hi Michael,

>  I think we just need the client to "subscribe" to a topic notification
for
>  "-partition-[0-9]+" to eliminate the polling

If pulsar users want to pub/sub a partitioned-topic, I think most of the
users would like to create a simple producer or consumer like following:
```
Producer producer = client.newProducer().topic(topic).create();
producer.sendAsync(msg);
```
```
client.newConsumer()
.topic(topic)
.subscriptionName(subscription)
.subscribe();
```
I think there is no reason for users to use `topicsPattern` if a pulsar
just wants to subscribe a partitioned-topic. In addition, `topicsPattern`
couldn't be used for producers.

So I think PIP-145 [0] will benefit for regex subscriptions.  And this PIP
[1] will benefit for the common partitioned-topic pub/sub scenario.

[0] https://github.com/apache/pulsar/issues/14505
[1] https://github.com/apache/pulsar/issues/19596

Thanks
Xiaoyu Hou

Michael Marshall  于2023年2月25日周六 01:29写道：

> > Just the way to implements partitioned-topic metadata
> > notification mechanism is much like notifications on regex sub changes
>
> Why do we need a separate notification implementation? The regex
> subscription feature is about discovering topics (not subscriptions)
> that match a regular expression. As Joe mentioned, I think we just
> need the client to "subscribe" to a topic notification for
> "-partition-[0-9]+" to eliminate the polling.
>
> Building on PIP 145, the work for this PIP would be in implementing a
> different `TopicsChangedListener` [1] so that the result of an added
> topic is to add a producer/consumer to the new partition.
>
> I support removing polling in our streaming platform, but I'd prefer
> to limit the number of notification systems we implement.
>
> Thanks,
> Michael
>
> [0] https://github.com/apache/pulsar/pull/16062
> [1]
> https://github.com/apache/pulsar/blob/82237d3684fe506bcb6426b3b23f413422e6e4fb/pulsar-client/src/main/java/org/apache/pulsar/client/impl/PatternMultiTopicsConsumerImpl.java#L169-L175
>
>
>
> On Fri, Feb 24, 2023 at 1:57 AM houxiaoyu  wrote:
> >
> > Hi Joe,
> >
> > When we use PartitionedProducerImpl or MultiTopicsConsumerImpl,  there
> is a
> > poll task to fetch the metadata of the partitioned-topic regularly for
> the
> > number of partitions updated.  This PIP wants to use a
> > notification mechanism to replace the metadata poll task.
> >
> > Just the way to implements partitioned-topic metadata
> > notification mechanism is much like notifications on regex sub changes
> >
> > Joe F  于2023年2月24日周五 13:37写道：
> >
> > > Why is this needed when we have notifications on regex sub changes?
> Aren't
> > > the partition names a well-defined regex?
> > >
> > > Joe
> > >
> > > On Thu, Feb 23, 2023 at 8:52 PM houxiaoyu  wrote:
> > >
> > > > Hi Asaf,
> > > > thanks for your reminder.
> > > >
> > > > ## Changing
> > > > I have updated the following changes to make sure the notification
> > > arrived
> > > > successfully:
> > > > 1. The watch success response `CommandWatchPartitionUpdateSuccess`
> will
> > > > contain all the concerned topics of this watcher
> > > > 2. The notification `CommandPartitionUpdate` will always contain all
> the
> > > > concerned topics of this watcher.
> > > > 3. The notification `CommandPartitionUpdate`contains a monotonically
> > > > increased version.
> > > > 4. A map
> `PartitonUpdateWatcherService#inFlightUpdate > > > Pair>` will keep track of the updating
> > > > 5. A timer will check the updating timeout through `inFlightUpdate`
> > > > 6. The client acks `CommandPartitionUpdateResult` to broker when it
> > > > finishes updating.
> > > >
> > > > ## Details
> > > >
> > > > The following mechanism could make sure the newest notification
> arrived
> > > > successfully, copying the description from GH:
> > > >
> > > > A new class, `org.apache.pulsar.PartitonUpdateWatcherService` will
> keep
> > > > track of watchers and will listen to the changes in the metadata.
> > > Whenever
> > > > a topic partition updates it checks if any watchers should be
> notified
> > > and
> > > > sends an update for all topics the watcher concerns through the
> > > ServerCnx.
> > > > Then we will record this request into a map,
> > > > `PartitonUpdateWatcherService#inFlightUpdate > > Pair >

Re: [DISCUSS] PIP-247: Notifications for partitions update

2023-02-23 Thread houxiaoyu

Hi Joe,

When we use PartitionedProducerImpl or MultiTopicsConsumerImpl,  there is a
poll task to fetch the metadata of the partitioned-topic regularly for the
number of partitions updated.  This PIP wants to use a
notification mechanism to replace the metadata poll task.

Just the way to implements partitioned-topic metadata
notification mechanism is much like notifications on regex sub changes

Joe F  于2023年2月24日周五 13:37写道：

> Why is this needed when we have notifications on regex sub changes? Aren't
> the partition names a well-defined regex?
>
> Joe
>
> On Thu, Feb 23, 2023 at 8:52 PM houxiaoyu  wrote:
>
> > Hi Asaf,
> > thanks for your reminder.
> >
> > ## Changing
> > I have updated the following changes to make sure the notification
> arrived
> > successfully:
> > 1. The watch success response `CommandWatchPartitionUpdateSuccess` will
> > contain all the concerned topics of this watcher
> > 2. The notification `CommandPartitionUpdate` will always contain all the
> > concerned topics of this watcher.
> > 3. The notification `CommandPartitionUpdate`contains a monotonically
> > increased version.
> > 4. A map `PartitonUpdateWatcherService#inFlightUpdate > Pair>` will keep track of the updating
> > 5. A timer will check the updating timeout through `inFlightUpdate`
> > 6. The client acks `CommandPartitionUpdateResult` to broker when it
> > finishes updating.
> >
> > ## Details
> >
> > The following mechanism could make sure the newest notification arrived
> > successfully, copying the description from GH:
> >
> > A new class, `org.apache.pulsar.PartitonUpdateWatcherService` will keep
> > track of watchers and will listen to the changes in the metadata.
> Whenever
> > a topic partition updates it checks if any watchers should be notified
> and
> > sends an update for all topics the watcher concerns through the
> ServerCnx.
> > Then we will record this request into a map,
> > `PartitonUpdateWatcherService#inFlightUpdate Pair > long/*timestamp*/>>`.  A timer will check this update timeout through
> > inFlightUpdate .  We will query all the concerned topics's partition if
> > this watcher has sent an update timeout and will resend it.
> >
> > The client acks `CommandPartitionUpdateResult` to broker when it finishes
> > updating.  The broker handle `CommandPartitionUpdateResult` request:
> >  - If CommandPartitionUpdateResult#version <
> > PartitonUpdateWatcherService#inFlightUpdate.get(watcherID).version,
> broker
> > ignores this ack.
> >  -  If CommandPartitionUpdateResult#version ==
> > PartitonUpdateWatcherService#inFlightUpdate.get(watcherID).version
> > - If CommandPartitionUpdateResult#success is true,  broker just
> removes
> > the watcherID from inFlightUpdate.
> > - If CommandPartitionUpdateResult#success is false,  broker removes
> the
> > watcherId from inFlightUpdate, and queries all the concerned topics's
> > partition and resend.
> >  - If CommandPartitionUpdateResult#version >
> > PartitonUpdateWatcherService#inFlightUpdate.get(watcherID).version, this
> > should not happen.
> >
> >  ## Edge cases
> > - Broker restarts or crashes
> > Client will reconnect to another broker, broker responses
> > `CommandWatchPartitionUpdateSuccess` with watcher concerned topics's
> > partitions.  We will call `PartitionsUpdateListener` if the connection
> > opens.
> > - Client acks fail or timeout
> > Broker will resend the watcher concerned topics's partitions either
> client
> > acks fail or acks timeout.
> > - Partition updates before client acks.
> > `CommandPartitionUpdate#version` monotonically increases every time it is
> > updated. If Partition updates before client acks, a greater version will
> be
> > put into `PartitonUpdateWatcherService#inFlightUpdate`.  The previous
> acks
> > will be ignored because the version is less than the current version.
> >
> >
> > Asaf Mesika  于2023年2月22日周三 21:33写道：
> >
> > > How about edge cases?
> > > In Andra's PIP he took into account cases where updates were lost, so
> he
> > > created a secondary poll. Not saying it's the best situation for your
> > case
> > > of course.
> > > I'm saying that when a broker sends an update CommandPartitionUpdate,
> how
> > > do you know it arrived successfully? From my memory, there is no ACK in
> > the
> > > protocol, saying "I'm the client, I got the update successfully" and
> only
> > > then it removed the "dirty" flag for that topic, for this watcher

Re: [DISCUSS] PIP-247: Notifications for partitions update

2023-02-23 Thread houxiaoyu

Hi Asaf,
thanks for your reminder.

## Changing
I have updated the following changes to make sure the notification arrived
successfully:
1. The watch success response `CommandWatchPartitionUpdateSuccess` will
contain all the concerned topics of this watcher
2. The notification `CommandPartitionUpdate` will always contain all the
concerned topics of this watcher.
3. The notification `CommandPartitionUpdate`contains a monotonically
increased version.
4. A map `PartitonUpdateWatcherService#inFlightUpdate>` will keep track of the updating
5. A timer will check the updating timeout through `inFlightUpdate`
6. The client acks `CommandPartitionUpdateResult` to broker when it
finishes updating.

## Details

The following mechanism could make sure the newest notification arrived
successfully, copying the description from GH:

A new class, `org.apache.pulsar.PartitonUpdateWatcherService` will keep
track of watchers and will listen to the changes in the metadata. Whenever
a topic partition updates it checks if any watchers should be notified and
sends an update for all topics the watcher concerns through the ServerCnx.
Then we will record this request into a map,
`PartitonUpdateWatcherService#inFlightUpdate>`.  A timer will check this update timeout through
inFlightUpdate .  We will query all the concerned topics's partition if
this watcher has sent an update timeout and will resend it.

The client acks `CommandPartitionUpdateResult` to broker when it finishes
updating.  The broker handle `CommandPartitionUpdateResult` request:
 - If CommandPartitionUpdateResult#version <
PartitonUpdateWatcherService#inFlightUpdate.get(watcherID).version, broker
ignores this ack.
 -  If CommandPartitionUpdateResult#version ==
PartitonUpdateWatcherService#inFlightUpdate.get(watcherID).version
- If CommandPartitionUpdateResult#success is true,  broker just removes
the watcherID from inFlightUpdate.
- If CommandPartitionUpdateResult#success is false,  broker removes the
watcherId from inFlightUpdate, and queries all the concerned topics's
partition and resend.
 - If CommandPartitionUpdateResult#version >
PartitonUpdateWatcherService#inFlightUpdate.get(watcherID).version, this
should not happen.

 ## Edge cases
- Broker restarts or crashes
Client will reconnect to another broker, broker responses
`CommandWatchPartitionUpdateSuccess` with watcher concerned topics's
partitions.  We will call `PartitionsUpdateListener` if the connection
opens.
- Client acks fail or timeout
Broker will resend the watcher concerned topics's partitions either client
acks fail or acks timeout.
- Partition updates before client acks.
`CommandPartitionUpdate#version` monotonically increases every time it is
updated. If Partition updates before client acks, a greater version will be
put into `PartitonUpdateWatcherService#inFlightUpdate`.  The previous acks
will be ignored because the version is less than the current version.


Asaf Mesika  于2023年2月22日周三 21:33写道：

> How about edge cases?
> In Andra's PIP he took into account cases where updates were lost, so he
> created a secondary poll. Not saying it's the best situation for your case
> of course.
> I'm saying that when a broker sends an update CommandPartitionUpdate, how
> do you know it arrived successfully? From my memory, there is no ACK in the
> protocol, saying "I'm the client, I got the update successfully" and only
> then it removed the "dirty" flag for that topic, for this watcher ID.
>
> Are there any other edge cases we can have? Let's be exhaustive.
>
>
>
> On Wed, Feb 22, 2023 at 1:14 PM houxiaoyu  wrote:
>
> > Thanks for your great suggestion Enrico.
> >
> > I agreed with you. It's more reasonable to add a
> > `supports_partition_update_watchers`  in `FeatureFlags`  to detect that
> the
> > connected broker supporting this feature , and add a new broker
> > configuration property `enableNotificationForPartitionUpdate` with
> default
> > value true, which is much like PIP-145.
> >
> > I have updated the descriptions.
> >
> > Enrico Olivelli  于2023年2月22日周三 17:26写道：
> >
> > > I support this proposal.
> > > Coping here my comments from GH:
> > >
> > > can't we enable this by default in case we detect that the connected
> > > Broker supports it ?
> > > I can't find any reason for not using this mechanism if it is
> available.
> > >
> > > Maybe we can set the default to "true" and allow users to disable it
> > > in case it impacts their systems in an unwanted way.
> > >
> > > Maybe It would be useful to have a way to disable the mechanism on the
> > > broker side as well
> > >
> > > Enrico
> > >
> > > Il giorno mer 22 feb 2023 alle ore 10:22 houxiaoyu
> &

Re: [DISCUSS] PIP-247: Notifications for partitions update

2023-02-22 Thread houxiaoyu

Thanks for your great suggestion Enrico.

I agreed with you. It's more reasonable to add a
`supports_partition_update_watchers`  in `FeatureFlags`  to detect that the
connected broker supporting this feature , and add a new broker
configuration property `enableNotificationForPartitionUpdate` with default
value true, which is much like PIP-145.

I have updated the descriptions.

Enrico Olivelli  于2023年2月22日周三 17:26写道：

> I support this proposal.
> Coping here my comments from GH:
>
> can't we enable this by default in case we detect that the connected
> Broker supports it ?
> I can't find any reason for not using this mechanism if it is available.
>
> Maybe we can set the default to "true" and allow users to disable it
> in case it impacts their systems in an unwanted way.
>
> Maybe It would be useful to have a way to disable the mechanism on the
> broker side as well
>
> Enrico
>
> Il giorno mer 22 feb 2023 alle ore 10:22 houxiaoyu
>  ha scritto:
> >
> > Hi Pulsar community:
> >
> > I opened a PIP to discuss "Notifications for partitions update"
> >
> > ### Motivation
> >
> > Pulsar client will poll brokers at fix time for checking the partitions
> > update if we publish/subscribe the partitioned topics with
> > `autoUpdatePartitions` as true. This causes unnecessary load for  both
> > clients and brokers since most of the time the number of partitions will
> > not change. In addition polling introduces latency in partitions update
> >  which is specified by `autoUpdatePartitionsInterval`.
> > This PIP would like to introduce a notification mechanism for partition
> > update, which is much like PIP-145 for regex subscriptions
> > https://github.com/apache/pulsar/issues/14505.
> >
> > For more details, please read the PIP at:
> > https://github.com/apache/pulsar/issues/19596
> > Looking forward to hearing your thoughts.
> >
> > Thanks,
> > Xiaoyu Hou
> > 
>

[DISCUSS] PIP-247: Notifications for partitions update

2023-02-22 Thread houxiaoyu

Hi Pulsar community:

I opened a PIP to discuss "Notifications for partitions update"

### Motivation

Pulsar client will poll brokers at fix time for checking the partitions
update if we publish/subscribe the partitioned topics with
`autoUpdatePartitions` as true. This causes unnecessary load for  both
clients and brokers since most of the time the number of partitions will
not change. In addition polling introduces latency in partitions update
 which is specified by `autoUpdatePartitionsInterval`.
This PIP would like to introduce a notification mechanism for partition
update, which is much like PIP-145 for regex subscriptions
https://github.com/apache/pulsar/issues/14505.

For more details, please read the PIP at:
https://github.com/apache/pulsar/issues/19596
Looking forward to hearing your thoughts.

Thanks,
Xiaoyu Hou

Re: [ANNOUNCE] Nicolò Boschi as new PMC member in Apache Pulsar

2023-01-29 Thread houxiaoyu

Congratulations !

Best
Xiaoyu Hou

Max Xu  于2023年1月30日周一 12:34写道：

> Congratulations! Nicolò
>
> Best,
> Max Xu
>
>
> On Fri, Jan 20, 2023 at 8:36 PM Lari Hotari  wrote:
>
> > Dear Community,
> >
> > We are thrilled to announce that Nicolò Boschi
> > (https://github.com/nicoloboschi) has been invited and has accepted the
> > role of member of the Apache Pulsar Project Management Committee (PMC).
> >
> > Nicolò Boschi has been a vital asset to our community, consistently
> > demonstrating his dedication and active participation through
> > significant contributions such as the development of the Pulsar Shell
> > and numerous bug fixes, security enhancements, and improvements to
> > Pulsar and its CI pipeline. In addition to his technical contributions,
> > Nicolò also plays an important role in reviewing pull requests and
> > ensuring the overall quality of our project. We look forward to his
> > continued contributions.
> >
> > On behalf of the Pulsar PMC, we extend a warm welcome and
> > congratulations to Nicolò Boschi.
> >
> > Best regards, Lari, on behalf of the Pulsar PMC
> >
>

Re: [ANNOUNCE] New Committer: Baodi Shi

2023-01-19 Thread houxiaoyu

Congratulations !

Zike Yang  于2023年1月19日周四 23:18写道：

> Congratulations! Baodi
>
> BR,
> Zike Yang
>
> On Thu, Jan 19, 2023 at 6:11 PM Jiuming Tao
>  wrote:
> >
> > Congrats
> >
> > > 2023年1月18日 21:35，Yunze Xu  写道：
> > >
> > > The Project Management Committee (PMC) for Apache Pulsar has invited
> > > Baodi Shi (https://github.com/shibd) to become a committer and we are
> > > pleased to announce that he has accepted.
> > >
> > > Being a committer enables easier contribution to the project since
> > > there is no need to go via the patch submission process. This should
> > > enable better productivity.
> > >
> > > Welcome and congratulations, Baodi Shi!
> > >
> > > Please join us in congratulating and welcoming Baodi Shi onboard!
> > >
> > > Thanks,
> > > Yunze on behalf of the Pulsar PMC
> >
>

Re: [ANNOUNCE] Bo Cong as new PMC member in Apache Pulsar

2023-01-18 Thread houxiaoyu

Congrats!!

Hou Xiaoyu

Nicolò Boschi  于2023年1月18日周三 22:10写道：

> Congrats!!
>
> Nicolò
>
> Il giorno mer 18 gen 2023 alle 15:06 Enrico Olivelli 
> ha scritto:
>
> > Congrats !
> >
> > Enrico
> >
> > Il giorno mer 18 gen 2023 alle ore 14:50 PengHui Li
> >  ha scritto:
> > >
> > > Hi all,
> > >
> > > The Apache Pulsar Project Management Committee (PMC) has invited Bo
> Cong
> > > (https://github.com/congbobo184) as a member of the PMC and we are
> > > pleased to announce that he has accepted.
> > >
> > > He is very active in the community in the past few years and made a lot
> > of
> > > great contributions
> > > such as transactions and schemas.
> > >
> > > Welcome Bo Cong to the Apache Pulsar PMC.
> > >
> > > Best Regards,
> > > Penghui on behalf of the Pulsar PMC
> >
> --
> Nicolò Boschi
>

Re: [Vote] PIP-231: Add metric for topic load failed

2023-01-05 Thread houxiaoyu

+1

Best
Xiaoyu Hou

Yunze Xu  于2023年1月5日周四 18:32写道：

> +1 (binding)
>
> Thanks,
> Yunze
>
> On Thu, Jan 5, 2023 at 5:45 PM Jiuming Tao
>  wrote:
> >
> > bump
> >
> > Jiuming Tao  于2022年12月27日周二 16:27写道：
> >
> > > Hello pulsar community,
> > >
> > > I'm starting the VOTE for PIP-231: Add metric for topic load failed.
> > >
> > > Motivation:
> > > Currently, we have a `topic_load_times` metric to track how long a
> topic
> > > load succeeds.
> > > But when loading a topic, there may be some chances the topic load
> failed
> > > due to MetadataStore or Bookkeeper, and we don't have related metrics
> to
> > > track it.
> > >
> > > For more details, please read the PIP at
> > > https://github.com/apache/pulsar/issues/18979
> > > Discuss thread:
> > > https://lists.apache.org/thread/h02wxj1yclo1o3r7otf9gp38hs0g03ym
> > >
> > > Thanks,
> > > Tao Jiuming
> > >
>

Re: [ANNOUNCE] Yunze Xu as a new PMC member in Apache Pulsar

2023-01-03 Thread houxiaoyu

Congrats!

Best,
Hou xiaoyu

Qiang Huang  于2023年1月3日周二 14:53写道：

> Congratulations!!!  Yunze
>
>
> Jun Ma  于2022年12月31日周六 17:26写道：
>
> > Congrats and well deserved!
> > 
> > From: Dave Fisher 
> > Sent: Saturday, December 31, 2022 1:52
> > To: dev@pulsar.apache.org 
> > Subject: Re: [ANNOUNCE] Yunze Xu as a new PMC member in Apache Pulsar
> >
> > Congratulations Yunze! Well deserved!
> >
> > All the best,
> > Dave
> >
> >
> > > On Dec 29, 2022, at 4:42 AM, Haiting Jiang 
> > wrote:
> > >
> > > Hi all,
> > >
> > > The Apache Pulsar Project Management Committee (PMC) has invited Yunze
> Xu
> > > (https://github.com/BewareMyPower) as a member of the PMC and we are
> > > pleased to announce that he has accepted.
> > >
> > > He is very active in the community in the past few years and made a lot
> > of great contributions.
> > >
> > > Welcome Yunze to the Apache Pulsar PMC.
> > >
> > > Best Regards,
> > > Haiting Jiang on behalf of the Pulsar PMC
> >
> >
>
> --
> BR,
> Qiang Huang
>

Re: [DISCUSS] Introduce oshi library to sensory OS resources

2022-12-21 Thread houxiaoyu

+1

Yubiao Feng  于2022年12月21日周三 11:59写道：

> +1
>
> On Mon, Dec 19, 2022 at 6:19 PM  wrote:
>
> >
> > Hi, All
> >
> > I would like to introduce a new library oshi[1] to help Apache Pulsar
> > sensory OS resources. It can help us to get away from the complex file
> > manipulation and cross-platform compatibility issues in some operating
> > systems.
> >
> > code example:   https://github.com/apache/pulsar/pull/18984
> >
> > Please feel free to left comments.
> >
> >
> > Best,
> > Mattison
> >
> >
> > [1] https://github.com/oshi/oshi
> >
>

Re: [DISCUSS] Change the default IO threads and listener threads of Java Client

2022-12-20 Thread houxiaoyu

+1

This change might bring thread number increment in case users create many
clients, but too many pulsar clients run in one machine is not a good use
case I think,  so this change looks good to me.

Thanks,
Xiaoyu Hou

 于2022年12月20日周二 12:25写道：

> +1
>
> My concern is whether this change will affect some users who are creating
> many clients. I think we can wait for other users to confirm it. (If this
> will be affected, maybe we can give it a max_io_thread_num and then expand
> the size from 1 to max_io_thread_num when adding a new consumer or producer)
>
>
> Best,
> Mattison
> On Dec 20, 2022, 11:17 +0800, PengHui Li , wrote:
> > Hi all,
> >
> > I noticed the Java Client (I haven't checked other clients) uses 1 IO
> > thread and 1 listener
> > thread by default. It will require users to update the thread
> configuration
> > if they have
> > multiple cores and desired high throughput.
> >
> > Here is the example that we change to 16 IO threads in
> > openmessaging benchmark
> >
> https://github.com/openmessaging/benchmark/blob/master/driver-pulsar/pulsar.yaml#L22
> >
> > We can apply the configuration of the threads based on the CPU cores. So
> > that for the
> > most common cases, users don't need to touch the thread configuration.
> >
> > ```
> > private int numIoThreads = Runtime.getRuntime().availableProcessors();
> > private int numListenerThreads =
> Runtime.getRuntime().availableProcessors();
> > ```
> >
> > WDYT?
> >
> > Thanks,
> > Penghui
>

Re: [ANNOUNCE] New Committer: Cong Zhao

2022-11-20 Thread houxiaoyu

Congrats! Cong

Best,
Xiaoyu Hou

Haiting Jiang  于2022年11月21日周一 12:10写道：

> The Project Management Committee (PMC) for Apache Pulsar has invited
> Cong Zhao (https://github.com/coderzc)
> to become a committer and we are pleased to announce that he has accepted.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
>
> Welcome and congratulations, Cong Zhao!
>
> Please join us in congratulating and welcoming Cong Zhao onboard!
>
> Best Regards,
> Haiting on behalf of the Pulsar PMC
>

Re: [DISCUSS] Remove "triage" series labels?

2022-11-20 Thread houxiaoyu

+1

Best,
Xiaoyu Hou

tison  于2022年11月17日周四 23:32写道：

> Hi,
>
> When squashing issue backlog, I noticed there're a number of "legacy" tags
> in series "traige/week-x".
>
> It seems the initiative has been halted and those labels don't provide
> continuous value. Thus I suggest we remove "triage" series labels to reduce
> engineering debt.
>
> What do you think?
>
> Best,
> tison.
>

Re: [DISCUSS] PIP-210

2022-11-17 Thread houxiaoyu

Hi Prashant,

I generally support this PIP.

Is it possible that we also add a flag to prevent messages pick this
partition for a period of time if the pendingMessage queue is full?

Assume that the partition has broken,  the following will happen:
1. The pendingMessage queue will be full;
2. Producer pick another partition to send the message
3. The pendingMessage queue will be clean by timeout mechanism.
4. Messages wil be picked to this broken parition again.
5. The pendingMessage queue will be full.


So we could add a flag to prevent messages pick this partition for a period
of time, e.g., 2*timeout, which will decrease the failures of sending.


Thanks,
Xiaoyu Hou



Prashant Kumar  于2022年11月17日周四 14:20写道：

> PIP: https://github.com/apache/pulsar/issues/18510
>
> Problem Statement
>
> When a topic is a partitioned topic and a partition is not available for
> producing messages, currently pulsar client will still try to produce
> messages on unavailable partitions, which it may not necessarily need to do
> in certain cases. Pulsar Client may simply pick up another partition and
> try producing in certain cases.
> Partition Unavailable
>
> There could be a plethora of reasons a partition can become unavailable.
> But the most prominent reason is partition is moving from one broker to
> another, and until every actor is in sync with which broker owns the
> partition, the partition will be unavailable for producing. Actors are
> producers, old broker, new broker.
> Client Behavior
>
> This is the typical produce code.
>
> producer.sendAsync(payLoad.getBytes(StandardCharsets.UTF_8));
>
> When send is called message is enqueued in a queue(called pending message
> queue) and the future is returned.
>
> And future is only completed when the message is picked from the queue and
> sent to the broker asynchronously and ack is received asynchronously again.
> Max size of the pending message queue is controlled by producer config
> maxPendingMessages.
>
> When pending message queue is full, the application will start getting
> publish failures. Pending message queue provide a cushion towards
> unavailable partitions. But again it has some limits.
>
> When another partitions can be picked
>
>1.
>
>When the message is not keyed. That means the message is not ordered
>based on a key.
>2.
>
>When routing mode is round-robin, that means a message can be produced
>to any of the partitions. So If a partition is unavailable try and pick
> up
>another partition for producing, by using the same round-robin
> algorithm.
>

Re: [ANNOUNCE] New Committer: Lin Chen

2022-11-13 Thread houxiaoyu

Congrats!

Best,
Xiaoyu Hou

PengHui Li  于2022年11月14日周一 12:28写道：

> The Project Management Committee (PMC) for Apache Pulsar has invited
> Lin Chen (https://github.com/lordcheng10)
> to become a committer and we are pleased to announce that he has accepted.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
>
> Welcome and congratulations, Lin Chen!
>
> Please join us in congratulating and welcoming Lin Chen onboard!
>
> Best Regards,
> Penghui on behalf of the Pulsar PMC
>

Re: [ANNOUNCE] New Committer: Zili Chen

2022-11-09 Thread houxiaoyu

Congratulations!

Best,
Xiaoyu Hou

Yu  于2022年11月10日周四 08:16写道：

> The Project Management Committee (PMC) for Apache Pulsar has invited Zili
> Chen (https://github.com/tisonkun)
> to become a committer and we are pleased to announce that he has accepted.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
>
> Welcome and congratulations, Zili Chen!
>
> Please join us in congratulating and welcoming Zili Chen onboard!
>
> Best Regards,
> Yu on behalf of the Pulsar PMC
>

Re: [DISCUSS] Release Pulsar 2.9.4

2022-11-03 Thread houxiaoyu

+1

Best,
Xiaoyu Hou

丛搏  于2022年11月3日周四 14:01写道：

> Hello, Pulsar community:
>
> I'd like to propose releasing Apache Pulsar 2.9.4. It's been about
> three months since 2.9.3 was released.
>
> There are 123 PRs [0] needed to cherry-pick in branch-2.9. I will
> cherry-pick these PRs for branch-2.9. Exclude some PRs that merge
> directly into branch-2.9.
>
> There are 33 PRs [1] opened. I'll follow up on each of those PRs to
> see if they will be completed soon or will need to be pushed to 2.9.5
>
> If you have any important fixes or any questions, please reply to this
> email, and we will evaluate whether to include them in 2.9.4
>
> Thanks,
> Bo
> [0] -
> https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.4+-label%3Acherry-picked%2Fbranch-2.9+is%3Amerged
> [1] -
> https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.4+is%3Aopen
> I will
>

Re: [ANNOUNCE] Haiting Jiang as a new PMC member in Apache Pulsar

2022-10-18 Thread houxiaoyu

Congrats!

Best,
Xiaoyu Hou

Hang Chen  于2022年10月18日周二 16:06写道：

> Hi all,
>
> The Apache Pulsar Project Management Committee (PMC) has invited Haiting
> Jiang
> (https://github.com/Jason918) as a member of the PMC and we are
> pleased to announce that he has accepted.
>
> He is very active in the community on GitHub.
>
> Welcome Haiting to the Apache Pulsar PMC
>
> Best Regards,
> Hang Chen on behalf of the Pulsar PMC
>

Re: [ANNOUNCE] New Committer: Qiang Huang

2022-10-13 Thread houxiaoyu

Congratulations Qiang Huang

Thanks,
Xiaoyu Hou

guo jiwei  于2022年10月14日周五 12:04写道：

> The Project Management Committee (PMC) for Apache Pulsar has invited
> Qiang Huang (https://github.com/hqebupt) to become a committer and
> we are pleased to announce that he has accepted.
>
> Qiang Huang (with Github id: hqebupt) contributed many improvements
> and bug fixes to Pulsar.
>
> Being a committer enables easier contribution to the project since
> there is no need to go via the patch submission process. This should
> enable better productivity.
>
> Welcome and Congratulations, Qiang Huang!
>
> Please join us in congratulating and welcoming Qiang Huang onboard!
>
>
> Regards
> Jiwei Guo on behalf of the Pulsar PMC
>

Re: [VOTE] Pulsar Release 2.10.2 Candidate 3

2022-10-13 Thread houxiaoyu

+1 (non-binding)

- Checksum and signatures
- Build on Mac, using JDK17
- Run Pulsar standalone and produce/consume case

Thanks,
Xiaoyu Hou

Haiting Jiang  于2022年10月13日周四 18:52写道：

> This is the third release candidate for Apache Pulsar, version 2.10.2.
>
> This release contains 252 commits by 57 contributors.
> https://github.com/apache/pulsar/compare/v2.10.1...v2.10.2-candidate-3
>
> CI for this release candidate
> https://github.com/Jason918/pulsar/pull/11
>
> *** Please download, test and vote on this release. This vote will stay
> open
> for at least 72 hours ***
>
> Note that we are voting upon the source (tag), binaries are provided for
> convenience.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.10.2-candidate-3/
>
> SHA-512 checksums:
>
> c136ef4f47b3b4edfb99d8a927ba70df19c12ac28d1711825bda4ef09e543d3d473ce732996244042ec3387f0e3cafdde6c8f5a0d7d18ad24429e781e65d3328
>  ./apache-pulsar-2.10.2-bin.tar.gz
>
> 1fd10fbb48e734dbb95f20b0d396cb9f875a0a1c93f44b639dc730379ce93bc59ce20bfba137f28897c1e5b3351b08ca3341863c903cf2b6d3dc7108046f2f8f
>  ./apache-pulsar-2.10.2-src.tar.gz
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1187/
>
> The tag to be voted upon:
> v2.10.2-candidate-3 (11b5df797b2e9cb48dfc38137f0b7ef736a8a47c)
> https://github.com/apache/pulsar/releases/tag/v2.10.2-candidate-3
>
> Pulsar's KEYS file containing PGP keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/pulsar/KEYS
>
> Docker images:
>
> https://hub.docker.com/layers/jason918/pulsar/2.10.2/images/sha256-6a501a0dc0e05b6bbd76e0f9edd1ff7223d0447bd318332dcf9551b48e831cf9
>
> https://hub.docker.com/layers/jason918/pulsar-all/2.10.2/images/sha256-fd3e027771f08eb224a3a9e8874514f0f258a0356059120d3f25f151f96506c8
>
> Please download the source package, and follow the
> release-candidate-validation doc to build
> and run the Pulsar standalone service.
>
> https://github.com/apache/pulsar/blob/master/wiki/release/release-candidate-validation.md
>
> Thanks,
> Haiting
>

Re: [DISCUSS] Decrease GitHub email notifications from apache/pulsar-* repos to this ML

2022-10-12 Thread houxiaoyu

+1
Very useful.

Michael Marshall  于2022年10月12日周三 12:52写道：

> Hi All,
>
> I had a brief discussion with Matteo about mailing list notifications
> for our apache/pulsar-* repos in this PR
> https://github.com/apache/pulsar-client-cpp/pull/42. Please see it for
> additional context.
>
> The outcome is a proposal to make all of our GitHub repos send their
> notifications to commits@ instead of dev@. Contributors will be able
> to subscribe to updates by using the GitHub "watch" feature.
>
> I created a sample PR here:
> https://github.com/apache/pulsar-client-go/pull/861.
>
> If there are no major objections, I plan to move forward with the rest
> of our repos later this week.
>
> Thanks,
> Michael
>

Re: [VOTE] Pulsar Release 2.10.2 Candidate 2

2022-10-07 Thread houxiaoyu

Hi Haiting,

There is a significant performance regression about publish
throughput, more context is here:
https://github.com/apache/pulsar/issues/17931

The fixed PR is here:
https://github.com/apache/pulsar/pull/17948

This should be a release blocker I think.

Thanks,
Xiaoyu Hou

Haiting Jiang  于2022年10月6日周四 10:46写道：

> This is the second release candidate for Apache Pulsar, version 2.10.2.
>
> This release contains 249 commits by 57 contributors.
> https://github.com/apache/pulsar/compare/v2.10.1...v2.10.2-candidate-2
>
> CI for this release candidate
> https://github.com/Jason918/pulsar/pull/10
>
> *** Please download, test and vote on this release. This vote will stay
> open
> for at least 72 hours ***
>
> Note that we are voting upon the source (tag), binaries are provided for
> convenience.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.10.2-candidate-2/
>
> SHA-512 checksums:
>
> 26dc11e1514aa286d934e2f9698f4a04def6424307dcc452324bf935e88ba97c2d75b480a88a98640010c0117293d128e389c3e4fa98ab51cfc19e9312f5d00a
>  ./apache-pulsar-2.10.2-bin.tar.gz
>
> 0eee2f47680966736acbdbdf309b0c7ccd4d10f737f49b6b8d9f5599a51d46568c1a0a18c75be6a44f78da60fe4287889d2e158fe530b20cee8b64411abe65f0
>  ./apache-pulsar-2.10.2-src.tar.gz
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1186/
>
> The tag to be voted upon:
> v2.10.2-candidate-2 (850c9448a5ac32e2f94988b8bf80955c93ef9d6c)
> https://github.com/apache/pulsar/releases/tag/v2.10.2-candidate-2
>
> Pulsar's KEYS file containing PGP keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/pulsar/KEYS
>
> Docker images:
>
> https://hub.docker.com/layers/jason918/pulsar/2.10.2/images/sha256-1ef93f17102e8193fc625fd5572f431d45935f7e2f11add3725a301c4321cef4
>
> https://hub.docker.com/layers/jason918/pulsar-all/2.10.2/images/sha256-6e6b49687b7debdf26feb71fedaa622de425885de5e2e7498dc476867cab85bc
>
> Please download the source package, and follow the
> release-candidate-validation doc to build
> and run the Pulsar standalone service.
>
> https://github.com/apache/pulsar/blob/master/wiki/release/release-candidate-validation.md
>
> Thanks,
> Haiting
>

Re: [VOTE] Pulsar Release 2.10.2 Candidate 1

2022-09-29 Thread houxiaoyu

+1 (non-binding)

- Checksum and signatures
- Build on Mac, using JDK17
- Run Pulsar standalone and produce/consume case

Thanks,
Xiaoyu Hou

Enrico Olivelli  于2022年9月29日周四 16:31写道：

> +1 (binding)
> - Apache RAT
> - Signatures/Digests
> - Built on Mac, using JDK 11 Temurin
> - Verified LICENSE files (using the script), both on the staged
> tarball and on the tarbal produced by building from source
> - Did a couple of smoke tests on Pulsar standalone, from the binary package
>
> Thanks for driving the release Haiting
>
> Enrico
>
> Il giorno gio 29 set 2022 alle ore 09:47 r...@apache.org
>  ha scritto:
> >
> > +1 (non-binding)
> >
> > - Checksum and signatures
> > - Run Go SDK produce/consume
> > - Run Pulsar standalone and produce/consume case
> >
> > --
> > Thanks
> > Xiaolong Ran
> >
> > guo jiwei  于2022年9月29日周四 11:30写道：
> >
> > > +1 (binding)
> > >
> > > - Checksum and signatures
> > > - Apache Rat check passes
> > > - Compile from source with JDK11
> > > - Validate Pub/Sub and Java functions
> > > - Validate Connectors
> > > - Validate Stateful functions
> > >
> > > Regards
> > > Jiwei Guo (Tboy)
> > >
> > >
> > > On Thu, Sep 29, 2022 at 12:26 AM Nicolò Boschi 
> > > wrote:
> > >
> > > > +1 (non binding)
> > > >
> > > >
> > > > - Checksum and signatures
> > > >
> > > > - Apache Rat check passes
> > > >
> > > > - Compile from source w JDK11
> > > >
> > > > - Build docker image from source
> > > >
> > > > - Run Pulsar standalone and produce-consume from CLI
> > > >
> > > > - Tested a couple of connectors (ElasticSink, JDBC sink) in K8S env
> > > >
> > > > Nicolò Boschi
> > > >
> > > >
> > > > Il giorno lun 26 set 2022 alle ore 13:42 Haiting Jiang <
> > > > jianghait...@gmail.com> ha scritto:
> > > >
> > > > > This is the first release candidate for Apache Pulsar, version
> 2.10.2.
> > > > >
> > > > > This release contains 244 commits by 57 contributors.
> > > > >
> https://github.com/apache/pulsar/compare/v2.10.1...v2.10.2-candidate-1
> > > > >
> > > > > Full CI on this release:
> > > > > https://github.com/Jason918/pulsar/pull/8
> > > > >
> > > > > *** Please download, test and vote on this release. This vote will
> stay
> > > > > open
> > > > > for at least 72 hours ***
> > > > >
> > > > > Note that we are voting upon the source (tag), binaries are
> provided
> > > for
> > > > > convenience.
> > > > >
> > > > > Source and binary files:
> > > > >
> > >
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.10.2-candidate-1/
> > > > >
> > > > > SHA-512 checksums:
> > > > >
> > > > >
> > > >
> > >
> fc7ed1947bf737b92ab097dc0eb500567668a6f64ed6e88af9d1f5bf9c266f77e50d3ea28944856f39afb0140232747693d61836b99eb22b7580e8a6cad4ce7d
> > > > >  ./apache-pulsar-2.10.2-bin.tar.gz
> > > > >
> > > > >
> > > >
> > >
> cab39ab5c24e2d01074d9169b641cdb80a59609462b664f6892905d6e995a72b02ab48cc8456cf90883a810af6085465cc8371df5e498bc1e13700ad0864d6af
> > > > >  ./apache-pulsar-2.10.2-src.tar.gz
> > > > >
> > > > > Maven staging repo:
> > > > >
> > >
> https://repository.apache.org/content/repositories/orgapachepulsar-1179/
> > > > >
> > > > > The tag to be voted upon:
> > > > > v2.10.2-candidate-1 (ddd642e77deacc42ad2542df39cbb22ef5217b25)
> > > > > https://github.com/apache/pulsar/releases/tag/v2.10.2-candidate-1
> > > > >
> > > > > Pulsar's KEYS file containing PGP keys we use to sign the release:
> > > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> > > > >
> > > > > Docker images:
> > > > >
> > > > >
> > > >
> > >
> https://hub.docker.com/layers/jason918/pulsar/2.10.2/images/sha256-2a6543a6f6b40af34760418ff199a771f91d85539e2cac692a524f3056d2226e
> > > > >
> > > > >
> > > >
> > >
> https://hub.docker.com/layers/jason918/pulsar-all/2.10.2/images/sha256-f9dc9b9ce224c69ab3616e7b3bbceafcb27504c81c791e2410115454a48c7837
> > > > >
> > > > > Please download the source package, and follow the
> > > > > release-candidate-validation doc to build
> > > > > and run the Pulsar standalone service.
> > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/pulsar/blob/master/wiki/release/release-candidate-validation.md
> > > > >
> > > > > Thanks,
> > > > > Haiting
> > > > >
> > > >
> > >
>

62 matches

Mail list logo