Re: [VOTE] Pulsar Node.js Client Release 1.11.1 Candidate 2

[Yunze Xu]

+1 (binding)

- Verified checksum and signatures
- Built from source and ran examples on macOS with Node.js v20.4.0
- Install the npm and ran examples on Rocky Linux 8 with Node.js v16.6.0

Thanks,
Yunze

On Wed, Jul 3, 2024 at 10:01 AM Baodi Shi  wrote:
>
> Hi everyone,
>
> This is the second release candidate for Apache Pulsar Node.js client,
> version 1.11.1.
> (Candidate 1 build failed, so skip voting for it.)
>
> It fixes the following issues:
> - https://github.com/apache/pulsar-client-node/compare/v1.11.0...v1.11.1-rc.2
>
> Please download the source files and review this release candidate:
> - Download the source package, verify shasum and asc
> - Follow the README.md to build and run the Pulsar Node.js client.
>
> The release candidate package has been published to the npm registry:
> https://www.npmjs.com/package/pulsar-client/v/1.11.1-rc.2
>
> You can install it and verify the package:
> "npm i pulsar-client@1.11.1-rc.2
> --pulsar_binary_host_mirror=https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/;
>
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Source files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/pulsar-client-node-1.11.1-rc.2/
>
> Pulsar's KEYS file containing PGP keys we use to sign the release:
> https://downloads.apache.org/pulsar/KEYS
>
> SHA-512 checksum:
> 2c6a73502cb96e7e9bae958dac14ec98eed9131e3ec9796c07e4095f269f6c33df0fef32aa2bea810f321a708e5184c7526e6bbf803a2f954823ad55612623d2
>  ./apache-pulsar-client-node-1.11.1.tar.gz
>
>
> The tag to be voted upon:
> v1.11.1-rc.2
> https://github.com/apache/pulsar-client-node/releases/tag/v1.11.1-rc.2
>
> Please review and vote on the release candidate #1 for the version
> 1.11.1, as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
> Thanks,
> Baodi Shi

[DISCUSS] Doubt about the widely used Netty Recycler in Pulsar

[Yunze Xu]

Hi all,

I'm doubting the value of the widely used Netty Recycler in Pulsar.
When I checked the recent commits today, I found even a pair of
Boolean and Integer is wrapped as a recyclable object. See
TopicExistsInfo in https://github.com/apache/pulsar/pull/22838. It's
really a mess, especially compared with a record implementation like:

```java
public record TopicExistsInfo(boolean exists, int partitions) {}
```

There was a similar doubt in an issue from early days in 2016:
https://github.com/netty/netty/issues/5904. We can also see
https://github.com/elastic/elasticsearch/pull/22452 from that issue
that ES disables the Netty recycler by default. Yeah, Netty even
provides a way to disable the recycler.

I don't look into the implementation at the moment so I asked ChatGPT for now:


Here are some cases when it is not recommended to use Netty Recycler:
1.Short-lived Objects: If objects in your application have very short
lifecycles, meaning they are created and destroyed frequently and
rapidly, using Recycler may add extra overhead as object pooling and
reuse may not provide significant performance improvements.
2. High Thread Safety Requirements: If your application demands high
thread safety for objects, and objects are passed between different
threads frequently, using an object pool may introduce potential
thread safety issues as object states are shared across threads.
3. Limited Memory Constraints: In some cases, object pools may consume
additional memory, especially when a large number of objects need to
be instantiated. If memory usage is a critical consideration, using an
object pool may increase memory consumption.
4. Low Object Creation Cost: If the cost of creating objects is low,
meaning object initialization overhead is minimal, and object reuse
has little impact on performance, then using an object pool may not be
worthwhile as the benefits of reuse may be offset by the management
overhead of the object pool.


At very least, it makes sense to me that short-lived objects and costs
with low object creation. i.e. some simple tuple structures can be
just implemented as a record. JVM GC is evolving and the recycling for
such objects should not be high.

Thanks,
Yunze

Re: [VOTE] PIP-364: Introduce a new load balance algorithm AvgShedder.

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Thu, Jun 27, 2024 at 8:39 AM Kai Wang  wrote:
>
> +1 (non-binding)
>
> Thanks
> Kai
>
> On 2024/06/26 03:00:02 thetumbled wrote:
> > Hi, Pulsar Community.
> >   I would like to start the voting thread for PIP-364: Introduce a new load 
> > balance algorithm AvgShedder.
> >   Proposal PR:  https://github.com/apache/pulsar/pull/22946
> >   Implementation PR: https://github.com/apache/pulsar/pull/22949
> >
> > Thanks,
> > Wenzhi Feng(thetumbled).

Re: [VOTE] Reactive Java client for Apache Pulsar 0.5.6 Candidate 1

[Yunze Xu]

+1 (binding)

- Verified checksum and signatures
- Built from source
- Verified the binaries

Thanks,
Yunze

On Sun, Jun 16, 2024 at 3:23 AM Chris Bono  wrote:
>
> Hi Yunze,
>
> Yes this is expected. On the source validation 
> (https://github.com/apache/pulsar-client-reactive/wiki/Release-process#release-validation)
>  the "diff" results always include the gradle pieces.
>
> For example:
> Only in pulsar-client-reactive-0.5.6-candidate-1-source/gradle: wrapper
> Only in pulsar-client-reactive-0.5.6-candidate-1-source: gradlew
> Only in pulsar-client-reactive-0.5.6-candidate-1-source: gradlew.bat
>
> Thanks,
> Chris
>
> On 2024/06/15 12:57:32 Yunze Xu wrote:
> > I noticed the `gradlew` and `gradlew.bat` files are missing. Is it expected?
> >
> > Thanks,
> > Yunze
> >
> > On Thu, Jun 13, 2024 at 10:37 PM Lari Hotari  wrote:
> > >
> > > +1 (binding)
> > >
> > > Validated source artifacts
> > > - checked sha512 checksum
> > > - checked signature
> > >
> > > Validated binaries
> > > - ran sample app
> > >
> > > -Lari
> > >
> > > On 2024/06/12 19:20:14 Chris Bono wrote:
> > > > Following PIP-205: Reactive Java client for Apache Pulsar (
> > > > https://github.com/apache/pulsar/issues/17335), this is release
> > > > candidate 1 for the Reactive Java client for Apache Pulsar, version 
> > > > 0.5.6.
> > > >
> > > > *** 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 in the Maven 
> > > > repository
> > > > are provided for convenience.
> > > >
> > > > Source package:
> > > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-reactive-0.5.6-candidate-1/
> > > >
> > > > SHA-512 checksums:
> > > > 0572aab3f35ad2b246894366ddeb0e32cf26dde67e7edde0adeb274be9384ec88fc8691d23c97add86b47b88118d32831b585f445d1f7216eb592d1244b2ec40
> > > >  pulsar-client-reactive-0.5.6-src.tar.gz
> > > >
> > > > Maven staging repo:
> > > > https://repository.apache.org/content/repositories/orgapachepulsar-1301/
> > > >
> > > > The tag to be voted upon:
> > > > v0.5.6-candidate-1 (59fea26f7a5a505098ddd110bd88167622871c73)
> > > > https://github.com/apache/pulsar-client-reactive/releases/tag/v0.5.6-candidate-1
> > > >
> > > > Please download the source package, and follow detailed instructions
> > > > for pulsar-client-reactive release validation at
> > > > https://github.com/apache/pulsar-client-reactive/wiki/Release-process#release-validation
> > > > .
> > > >
> > > > Best regards
> > > >
> > > > Chris
> > > >
> >

Re: [VOTE] PIP-358: let resource weight work for OverloadShedder, LeastLongTermMessageRate, ModularLoadManagerImpl.

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Fri, Jun 14, 2024 at 8:30 PM guo jiwei  wrote:
>
> +1 (binding)
>
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Fri, Jun 14, 2024 at 11:04 AM Yubiao Feng
>  wrote:
>
> > +1 (binding)
> >
> > Thanks
> > Yubiao Feng
> >
> > On Fri, Jun 14, 2024 at 10:09 AM thetumbled  wrote:
> >
> > > Hi, Pulsar Community.
> > >  I would like to start the voting thread for PIP-358: let resource
> > > weight work for OverloadShedder, LeastLongTermMessageRate,
> > > ModularLoadManagerImpl.
> > >  Proposal PR: https://github.com/apache/pulsar/pull/22889
> > >  ; Implementation
> > > PR: https://github.com/apache/pulsar/pull/22888
> > >  ;
> > > Thanks,
> > > Wenzhi Feng(thetumbled).
> >

Re: [VOTE] Reactive Java client for Apache Pulsar 0.5.6 Candidate 1

[Yunze Xu]

I noticed the `gradlew` and `gradlew.bat` files are missing. Is it expected?

Thanks,
Yunze

On Thu, Jun 13, 2024 at 10:37 PM Lari Hotari  wrote:
>
> +1 (binding)
>
> Validated source artifacts
> - checked sha512 checksum
> - checked signature
>
> Validated binaries
> - ran sample app
>
> -Lari
>
> On 2024/06/12 19:20:14 Chris Bono wrote:
> > Following PIP-205: Reactive Java client for Apache Pulsar (
> > https://github.com/apache/pulsar/issues/17335), this is release
> > candidate 1 for the Reactive Java client for Apache Pulsar, version 0.5.6.
> >
> > *** 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 in the Maven 
> > repository
> > are provided for convenience.
> >
> > Source package:
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-reactive-0.5.6-candidate-1/
> >
> > SHA-512 checksums:
> > 0572aab3f35ad2b246894366ddeb0e32cf26dde67e7edde0adeb274be9384ec88fc8691d23c97add86b47b88118d32831b585f445d1f7216eb592d1244b2ec40
> >  pulsar-client-reactive-0.5.6-src.tar.gz
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachepulsar-1301/
> >
> > The tag to be voted upon:
> > v0.5.6-candidate-1 (59fea26f7a5a505098ddd110bd88167622871c73)
> > https://github.com/apache/pulsar-client-reactive/releases/tag/v0.5.6-candidate-1
> >
> > Please download the source package, and follow detailed instructions
> > for pulsar-client-reactive release validation at
> > https://github.com/apache/pulsar-client-reactive/wiki/Release-process#release-validation
> > .
> >
> > Best regards
> >
> > Chris
> >

Re: [VOTE] PIP-357: Correct the conf name in load balance module.

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Wed, Jun 5, 2024 at 6:25 PM thetumbled  wrote:
>
> Hi PengHui,
> The current design is not to remove the old one directly, but deprecate it. 
> We are still comptible with the old cluster in following way:
> - If a configuration is not the default configuration, use that configuration.
> - If both the new and the old are configured different from the default 
> value, use the new one.
> So user upgrading to the new version without doing any change will not meet 
> any problem.
>
> Regards,
> Wenzhi Feng.
>
> On 2024/06/05 09:37:43 PengHui Li wrote:
>  Hi Wenzhi,
> 
>  Thanks for driving the proposal.
> 
>  The old configuration name should not be removed directly.
>  It might break users when they upgrade to the new cluster.
>  Instead, we can move it to the `Deprecated settings` section
>  and use `-1` as the default value. If the user sets it to a positive 
> number,
>  we should use the old configuration to ensure compatibility.
> 
>  If the existing user wants to move to the new configuration name, they
>  should
>  set the old one to -1 or just delete it.
> 
>  Regards,
>  Penghui
> 
>  On Wed, Jun 5, 2024 at 11:15 AM Kai Wang  wrote:
> 
>   +1 non-binding
>  
>   Thank you,
>   Kai
>  
>   On 2024/06/05 02:32:51 thetumbled wrote:
>Hi, Pulsar Community.
>  I would like to start the voting thread for PIP-357: Correct 
> the conf
>   name in load balance module.
>  Proposal PR:  https://github.com/apache/pulsar/pull/22823
>  Implementation PR: 
> https://github.com/apache/pulsar/pull/22824
>   
>Thanks,
>Wenzhi Feng(thetumbled).
>  
> 

Re: [VOTE] Release Apache Pulsar 3.3.0 based on 3.3.0-candidate-4

[Yunze Xu]

+1 (binding)

- Verified signature and checksums
- Verified the docker image with the C++ client
(https://github.com/BewareMyPower/pulsar-client-cpp/pull/31)
- Built from source with JDK 17 on macOS
- Verified standalone with produce and consume

Thanks,
Yunze

On Wed, Jun 5, 2024 at 4:28 AM Andrey Yegorov  wrote:
>
> +1 (non-binding)
>
> * built from the tag
> * built from archived sources (jdk 17, mac)
> * tested pulsar standalone (jdk 17, mac)
> * checked console consumer and producer
> * checked pulsar-admin
>  * spot-checked staging maven repo
>
> On Mon, Jun 3, 2024 at 3:52 AM Cong Zhao  wrote:
>
> > Hello Apache Pulsar Community,
> >
> > This is a call for the vote to release the Apache Pulsar version 3.3.0
> > based on 3.3.0-candidate-4.
> >
> > Included changes since the previous release:
> > https://github.com/apache/pulsar/milestone/38?closed=1
> >
> > *** Please download, test and vote on this release. This vote will stay
> > open
> > for at least 72 hours ***
> >
> > Only votes from PMC members are binding, but members of the community are
> > encouraged to test the release and vote with "(non-binding)".
> >
> > Note that we are voting upon the source (tag), binaries are provided for
> > convenience.
> >
> > The release candidate is available at:
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-3.3.0-candidate-4/
> >
> > SHA-512 checksums:
> >
> > a19f80caa7dcc92d6df235af9f71e90d9ab52739e2d7d1ddc59944ed11be8f5f6a083db4792cafd87802d68ef9edce88e1ed91ee43cac2a98c3782b8925f07f6
> >
> > 03692f2b6d574ce523418850d47391b9aa9f71a2bde0b593d6e1eaaf34eb6ebe080e598231d6faf2902a9f071192c0a6982403095a9374d4357b7bebb18e5e93
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachepulsar-1300
> >
> > The tag to be voted upon:
> > v3.3.0-candidate-4 (commit c0aab493aafa5386dbf93c0b58a66a666aeba17a)
> > https://github.com/apache/pulsar/releases/tag/v3.3.0-candidate-4
> >
> > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > https://downloads.apache.org/pulsar/KEYS
> >
> > Docker images:
> > docker pull czcoder/pulsar3.3.0-c0aab49
> >
> > https://hub.docker.com/layers/czcoder/pulsar/3.3.0-c0aab49/images/sha256-996c6babec1f887cf2f43cac0692e06f879364fe87372fcb6c8b9d3ac779c7d6?context=explore
> > docker pull czcoder/pulsar-all:3.3.0-c0aab49
> >
> > https://hub.docker.com/layers/czcoder/pulsar-all/3.3.0-c0aab49/images/sha256-dd781dfcc72dfb3db6c0053c656dfdb750c8d36e4c57f4bbad87aee4a9cdce28?context=explore
> >
> > Please download the source package, and follow the README to build
> > and run the Pulsar standalone service.
> >
> > More advanced release validation instructions can be found at
> > https://pulsar.apache.org/contribute/validate-release-candidate/
> >
> > Thanks,
> > Cong Zhao
> >

Re: [DISCUSS] Report an error when seeking a multi-topics consumer that subscribes no topics

[Yunze Xu]

> I prefer not to break the current behavior as it's probably not a bug.

I agree. For now, let's keep the same behavior if there are no strong
objections from any existing user.

Thanks,
Yunze

On Thu, May 30, 2024 at 4:33 PM Zike Yang  wrote:
>
> I think the key point is whether we should consider a regex consumer
> without any subscribed topics as a valid consumer.
>
> > For example, when users create a regex consumer that subscribes to
> topics ("tp0", "tp1", ..., "tpN") and seek to the earliest, they might
> expect to consume messages from these topics. However, if they used a
> wrong regex like "tp*" (it should be "tp.*), then they might find no
> messages are available even if they're sure there is at least one
> non-empty topic whose name starts at "tp" from the topic stats.
>
> Actually, for this example, if we treat a consumer without any
> subscribed topics as an invalid consumer, we should throw an expcetion
> when the regex consumer first subscribes, instead of waiting until the
> seek to inform the user that there are no topics. Currently, however,
> no exception is thrown when a regex consumer subscribes without any
> topics.
>
> I prefer not to break the current behavior as it's probably not a bug.
> Alternatively, we could introduce a new option for users who do not
> want to seek on the consumer without any topics.
>
> BR,
> Zike Yang
>
> On Thu, May 30, 2024 at 1:10 AM Yunze Xu  wrote:
> >
> > For example, when users create a regex consumer that subscribes to
> > topics ("tp0", "tp1", ..., "tpN") and seek to the earliest, they might
> > expect to consume messages from these topics. However, if they used a
> > wrong regex like "tp*" (it should be "tp.*), then they might find no
> > messages are available even if they're sure there is at least one
> > non-empty topic whose name starts at "tp" from the topic stats.
> >
> > Thanks,
> > Yunze
> >
> > On Wed, May 29, 2024 at 7:32 PM Enrico Olivelli  wrote:
> > >
> > > Il giorno mer 29 mag 2024 alle ore 11:10 Baodi Shi  ha
> > > scritto:
> > >
> > > > +1
> > > >
> > > >
> > > > Thanks,
> > > > Baodi Shi
> > > >
> > > >
> > > > On May 29, 2024 at 14:50:12, Yunze Xu  wrote:
> > > >
> > > > > Hi community,
> > > > >
> > > > > Recently I found the behavior of seeking a multi-topics consumer is
> > > > > intuitive. If there are no internal consumers, the `seek` call will
> > > > > just succeed silently.
> > > >
> > >
> > >
> > > > >
> > > > > If a consumer subscribes with a regex and no topics are found, users
> > > > > might think the seek operation succeeds while no topics are sought.
> > > > >
> > > > > I suggest throwing an exception in this case to notify users that the
> > > > > consumer to seek is a multi-topics consumer that contains no topics.
> > > > > It's a breaking change so I'd like to hear more voices in the mail
> > > >
> > >
> > > What happens if it subscribed to a regex which "currently" doesn't not
> > > match any topics ?
> > > Maybe this is intentional in the application design as maybe you have
> > > dynamic topics
> > >
> > > Giving an error or failing silently doesn't fix the problem.
> > > If the application is sure that you must have at least N topics then we
> > > should make this configurable somewhere.
> > > The difference between "zero topics" or "one topic" is very small, if your
> > > application expects to subscribe to 100 topics.
> > >
> > >
> > > Enrico
> > >
> > >
> > >
> > > > > list.
> > > > >
> > > > > For now, I report an error for the C++ client [1], which might also
> > > > > affect the Python and Node.js clients. But the behavior of the Java
> > > > > client does not change.
> > > > >
> > > > > [1] https://github.com/apache/pulsar-client-cpp/pull/426
> > > > >
> > > > > Thanks,
> > > > > Yunze
> > > > >
> > > >

Re: [DISCUSS] Report an error when seeking a multi-topics consumer that subscribes no topics

[Yunze Xu]

For example, when users create a regex consumer that subscribes to
topics ("tp0", "tp1", ..., "tpN") and seek to the earliest, they might
expect to consume messages from these topics. However, if they used a
wrong regex like "tp*" (it should be "tp.*), then they might find no
messages are available even if they're sure there is at least one
non-empty topic whose name starts at "tp" from the topic stats.

Thanks,
Yunze

On Wed, May 29, 2024 at 7:32 PM Enrico Olivelli  wrote:
>
> Il giorno mer 29 mag 2024 alle ore 11:10 Baodi Shi  ha
> scritto:
>
> > +1
> >
> >
> > Thanks,
> > Baodi Shi
> >
> >
> > On May 29, 2024 at 14:50:12, Yunze Xu  wrote:
> >
> > > Hi community,
> > >
> > > Recently I found the behavior of seeking a multi-topics consumer is
> > > intuitive. If there are no internal consumers, the `seek` call will
> > > just succeed silently.
> >
>
>
> > >
> > > If a consumer subscribes with a regex and no topics are found, users
> > > might think the seek operation succeeds while no topics are sought.
> > >
> > > I suggest throwing an exception in this case to notify users that the
> > > consumer to seek is a multi-topics consumer that contains no topics.
> > > It's a breaking change so I'd like to hear more voices in the mail
> >
>
> What happens if it subscribed to a regex which "currently" doesn't not
> match any topics ?
> Maybe this is intentional in the application design as maybe you have
> dynamic topics
>
> Giving an error or failing silently doesn't fix the problem.
> If the application is sure that you must have at least N topics then we
> should make this configurable somewhere.
> The difference between "zero topics" or "one topic" is very small, if your
> application expects to subscribe to 100 topics.
>
>
> Enrico
>
>
>
> > > list.
> > >
> > > For now, I report an error for the C++ client [1], which might also
> > > affect the Python and Node.js clients. But the behavior of the Java
> > > client does not change.
> > >
> > > [1] https://github.com/apache/pulsar-client-cpp/pull/426
> > >
> > > Thanks,
> > > Yunze
> > >
> >

[DISCUSS] Report an error when seeking a multi-topics consumer that subscribes no topics

[Yunze Xu]

Hi community,

Recently I found the behavior of seeking a multi-topics consumer is
intuitive. If there are no internal consumers, the `seek` call will
just succeed silently.

If a consumer subscribes with a regex and no topics are found, users
might think the seek operation succeeds while no topics are sought.

I suggest throwing an exception in this case to notify users that the
consumer to seek is a multi-topics consumer that contains no topics.
It's a breaking change so I'd like to hear more voices in the mail
list.

For now, I report an error for the C++ client [1], which might also
affect the Python and Node.js clients. But the behavior of the Java
client does not change.

[1] https://github.com/apache/pulsar-client-cpp/pull/426

Thanks,
Yunze

Re: [VOTE] PIP-354: apply topK mechanism to ModularLoadManagerImpl

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Sun, May 26, 2024 at 10:14 PM thetumbled  wrote:
>
> Hi, Pulsar Community.
>   I would like to start the voting thread for PIP-354: apply topK mechanism 
> to ModularLoadManagerImpl.
>   Proposal PR:  https://github.com/apache/pulsar/pull/22765
>   Implementation PR: https://github.com/apache/pulsar/pull/22753
>
> Thanks,
> Wenzhi Feng(thetumbled).

Re: [VERIFY] Pulsar Release 3.3.0 Candidate 1

[Yunze Xu]

-1 (binding)

There seems something wrong with the docker image, see
https://github.com/BewareMyPower/pulsar-client-cpp/actions/runs/9121814458/job/25082141665?pr=31

After upgrading the dependency, the Pulsar standalone in CI of
pulsar-client-cpp cannot be started (always stuck in waiting for the
metrics ready).

Thanks,
Yunze

On Fri, May 17, 2024 at 12:06 AM Cong Zhao  wrote:
>
> This is the first release candidate for Apache Pulsar version 3.3.0.
>
> It fixes the following issues:
> https://github.com/apache/pulsar/milestone/38?closed=1
>
> *** Please download, test and verify on this release. This release
> candidate verification will stay open until May 22 ***
>
> 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.3.0-candidate-1/
>
> SHA-512 checksums:
>
> 52a29b59b53e15f295acb88afdf8c1ad9a18fc3befef61310565a527df1991a96b54d570a13cba2b9b390c7119b4b14d85cfd519c179c4c138c6e35276902c5f
>
> apache-pulsar-3.3.0-bin.tar.gz
>
> 5e9752a03a85672374759d19c75f37d44e52ef77912f0e4169f7995abce9fa204e0ce79875bb8055f6e4588eca451da8344ee83e31335488b2fcc464b7b34391
>
> apache-pulsar-3.3.0-src.tar.gz
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1293/
>
> The tag to verify:
> v3.3.0-candidate-1 (3c3ce71c13a9cc0982089e7d87d97bc89a4a26c2)
> https://github.com/apache/pulsar/commits/v3.3.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:
> docker pull czcoder/pulsar:3.3.0-3c3ce71
> https://hub.docker.com/layers/czcoder/pulsar/3.3.0-3c3ce71/images/sha256-ce6ab616eca8b0679a9d0cec50578dc744d7091d305cf4d2af8f533fe4e38641?context=explore
>
> pulsar-all images:
> docekr pull czcoder/pulsar-all:3.3.0-3c3ce71
> https://hub.docker.com/layers/czcoder/pulsar-all/3.3.0-3c3ce71/images/sha256-bd8b6bb3fbbacdf4d21b2a70cd3b4be7f0de839d1649652eda005f3ed46b78fd?context=explore
>
>
> 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
> Cong Zhao

Re: [DISCUSS] Release Apache Pulsar Python Client 3.4.1

[Yunze Xu]

> I tried but it didn't work.

Could you share the CI workflow so I can take a look? Meanwhile, would
you like to start the release for Python client 3.5.1?

Thanks,
Yunze

On Sat, May 11, 2024 at 5:54 PM Zixuan Liu  wrote:
>
> > Please release 3.5.1 rather than 3.4.1 because 3.5.0 is already
> released. It's too heavy to maintain old releases for client libraries
> for now.
>
> Let's go to 3.5.1.
>
> > However, it would be better to remove the `functions` component from
> pulsar-client-python because the Python client itself never uses these
> dependencies. See my discussion [1] before. Since python functions is
> maintained in the Pulsar main repository, we should maintain the extra
> dependencies in the Pulsar main repo as well.
>
> Good idea +1.
>
> > Would this release block the Pulsar 3.3.0 release?
>
> Yes, the current Python client will cause a particularly long time(2 hours)
> to build a pulsar ARM image.
>
> > If yes, a quicker way to fix it was to add a `requirements.txt` that
> includes a proper
> version of grpcio and then run `python -m pip install -r
> python/requirements.txt`.
>
> I tried but it didn't work.
>
> Thanks,
> Zixuan
>
>
> Yunze Xu  于2024年5月11日周六 12:25写道：
>
> > Sorry I missed the discussion link:
> > https://lists.apache.org/thread/5s2l9vgt5f973psb6xlttpmy4rpym7zh
> >
> > Would this release block the Pulsar 3.3.0 release? If yes, a quicker
> > way to fix it was to add a `requirements.txt` that includes a proper
> > version of grpcio and then run `python -m pip install -r
> > python/requirements.txt`.
> >
> > Here is an example:
> >
> > ```
> > pulsar-client == 3.5.0
> > protobuf>=3.6.1,<=3.20.3
> > grpcio >= 1.60.0
> > apache-bookkeeper-client>=4.16.1
> > prometheus_client
> > ratelimit
> > ```
> >
> > Thanks,
> > Yunze
> >
> > On Sat, May 11, 2024 at 12:19 PM Yunze Xu  wrote:
> > >
> > > Please release 3.5.1 rather than 3.4.1 because 3.5.0 is already
> > > released. It's too heavy to maintain old releases for client libraries
> > > for now.
> > >
> > > However, it would be better to remove the `functions` component from
> > > pulsar-client-python because the Python client itself never uses these
> > > dependencies. See my discussion [1] before. Since python functions is
> > > maintained in the Pulsar main repository, we should maintain the extra
> > > dependencies in the Pulsar main repo as well.
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Wed, May 8, 2024 at 11:26 PM Zixuan Liu  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > https://github.com/apache/pulsar-client-python/pull/174 breaks the
> > > > python-client installation in the pulsar arm image, and then the
> > release
> > > > manager of pulsar@3.3.0 will take about 2 hours to build the grpcio
> > wheel,
> > > > please see
> > > >
> > https://github.com/nodece/pulsar-python-deps-build/actions/runs/8891459473/job/24418839959#step:6:315
> > > > for
> > > > details.
> > > >
> > > > https://github.com/apache/pulsar-client-python/pull/211 fixes that,
> > but I'm
> > > > not sure if a new version will be released.
> > > >
> > > > Thanks,
> > > > Zixuan
> >

[DISCUSSION][CPP Client] Build the RPM package for the GCC 5 ABI

[Yunze Xu]

Hi all,

Currently, the pre-built RPM packages are built on CentOS 7 with GCC
4.8 to keep the binary compatibility with CentOS 7 users. A breaking
ABI change was changed since GCC 5 though users can add the
`-D_GLIBCXX_USE_CXX11_ABI=0` option to keep the compatibility.

In short, for GCC>=5, to link the RPM package of the Pulsar C++ client,
- `-D_GLIBCXX_USE_CXX11_ABI=0` option must be added
- If there are other dependencies that are built with GCC>=5, there is
no way to make them compatible

Since CentOS 7 will reach the EOL on June 30, 2024, it's time to
deprecate the support for CentOS 7 users.

[1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

Thanks,
Yunze

Re: [DISCUSS] Release Apache Pulsar Python Client 3.4.1

[Yunze Xu]

Sorry I missed the discussion link:
https://lists.apache.org/thread/5s2l9vgt5f973psb6xlttpmy4rpym7zh

Would this release block the Pulsar 3.3.0 release? If yes, a quicker
way to fix it was to add a `requirements.txt` that includes a proper
version of grpcio and then run `python -m pip install -r
python/requirements.txt`.

Here is an example:

```
pulsar-client == 3.5.0
protobuf>=3.6.1,<=3.20.3
grpcio >= 1.60.0
apache-bookkeeper-client>=4.16.1
prometheus_client
ratelimit
```

Thanks,
Yunze

On Sat, May 11, 2024 at 12:19 PM Yunze Xu  wrote:
>
> Please release 3.5.1 rather than 3.4.1 because 3.5.0 is already
> released. It's too heavy to maintain old releases for client libraries
> for now.
>
> However, it would be better to remove the `functions` component from
> pulsar-client-python because the Python client itself never uses these
> dependencies. See my discussion [1] before. Since python functions is
> maintained in the Pulsar main repository, we should maintain the extra
> dependencies in the Pulsar main repo as well.
>
> Thanks,
> Yunze
>
> On Wed, May 8, 2024 at 11:26 PM Zixuan Liu  wrote:
> >
> > Hi all,
> >
> > https://github.com/apache/pulsar-client-python/pull/174 breaks the
> > python-client installation in the pulsar arm image, and then the release
> > manager of pulsar@3.3.0 will take about 2 hours to build the grpcio wheel,
> > please see
> > https://github.com/nodece/pulsar-python-deps-build/actions/runs/8891459473/job/24418839959#step:6:315
> > for
> > details.
> >
> > https://github.com/apache/pulsar-client-python/pull/211 fixes that, but I'm
> > not sure if a new version will be released.
> >
> > Thanks,
> > Zixuan

Re: [DISCUSS] Release Apache Pulsar Python Client 3.4.1

[Yunze Xu]

Please release 3.5.1 rather than 3.4.1 because 3.5.0 is already
released. It's too heavy to maintain old releases for client libraries
for now.

However, it would be better to remove the `functions` component from
pulsar-client-python because the Python client itself never uses these
dependencies. See my discussion [1] before. Since python functions is
maintained in the Pulsar main repository, we should maintain the extra
dependencies in the Pulsar main repo as well.

Thanks,
Yunze

On Wed, May 8, 2024 at 11:26 PM Zixuan Liu  wrote:
>
> Hi all,
>
> https://github.com/apache/pulsar-client-python/pull/174 breaks the
> python-client installation in the pulsar arm image, and then the release
> manager of pulsar@3.3.0 will take about 2 hours to build the grpcio wheel,
> please see
> https://github.com/nodece/pulsar-python-deps-build/actions/runs/8891459473/job/24418839959#step:6:315
> for
> details.
>
> https://github.com/apache/pulsar-client-python/pull/211 fixes that, but I'm
> not sure if a new version will be released.
>
> Thanks,
> Zixuan

Re: [DISCUSS] Apache Pulsar 3.3.0 release

[Yunze Xu]

Please include https://github.com/apache/pulsar/pull/22665 in 3.3.0
because it fixes a regression introduced by PIP-342
(https://github.com/apache/pulsar/pull/22179).

Thanks,
Yunze

On Mon, May 6, 2024 at 11:52 AM Cong Zhao  wrote:
>
> Hello Enrico,
>
> Can you list which PRs are important? I see that only has 6 PRs closed on 
> 4.17.1.
>
> On 2024/04/29 07:02:34 Enrico Olivelli wrote:
> > +1
> >
> > Thanks for driving the release.
> >
> > FYI On the BookKeeper side there are some fixes about metrics, maybe we
> > could ask for a new 4.17.1 release
> >
> > Enrico
> >
> > Il giorno dom 28 apr 2024 alle ore 21:04 PengHui Li  ha
> > scritto:
> >
> > > +1
> > >
> > > Thanks for driving the release.
> > >
> > > Penghui
> > >
> > > On Sun, Apr 28, 2024 at 8:17 PM Cong Zhao  wrote:
> > >
> > > > Hi community,
> > > > It has been more than three months since the release of 3.2.0. we now
> > > > have more than 280 commits
> > > > <
> > > >
> > > https://github.com/apache/pulsar/pulls?q=is%3Apr+milestone%3A3.3.0+is%3Amerged+
> > > > >
> > > > and
> > > > 11 PIPs
> > > > <
> > > >
> > > https://github.com/apache/pulsar/pulls?q=is%3Apr+milestone%3A3.3.0+is%3Amerged+label%3Atype%2FPIP+
> > > > >
> > > > merged. We'd better prepare for the 3.3.0 release. I would like to cut
> > > > branch-3.3 in the next week and freeze the code for two weeks.
> > > > Please leave any ideas or concerns.
> > > >
> > > >
> > > > Regards
> > > > Cong Zhao
> > > >
> > >
> >

Re: [DISCUSS] Restore the slf4j version to 1.7.x

[Yunze Xu]

> 1.7 has not been maintained for almost 2 years.

Logging is only a very simple part. SLF4J is even just a logging
facade that has less chance to suffer CVEs like log4j2. Unless there
is any CVE found for slf4j, breaking the user case is worse than
upgrading the slf4j.

> when the slf4j version is inconsistent, we still need to use ``.

Yes, that's why we exclude some slf4j dependencies from 3rd party
dependencies like confluent-schema-registry in KSN. However, back to
the discussion, the slf4j upgrade breaks many downstream projects. At
least, nearly all StreamNative's plugins are affected by this breaking
change. For example, KSN chooses to exclude all slf4j dependencies
from other dependencies and depend on the slf4j dependency from
`pulsar-*`. So a refactoring of pom.xml is needed for the latest
Pulsar.

Thanks,
Yunze

On Sat, Apr 27, 2024 at 12:47 PM Zixuan Liu  wrote:
>
> > I don't think so. As a logging facade, there is no convincing reason
> > to keep it latest unless some CVEs.
>
> I think it's better to keep up with the latest version, as we always get
> support from the community. 1.7 has not been maintained for almost 2 years.
>
> >The point is not related to how I should resolve the dependency issue.
> > It is how you care for the downstream users.
>
> We should care for the downstream users.
>
> I think the root cause is the pulsar-** includes the slf4j-api dependency,
> so the users must use the same version of slf4j-xxx(simple, reload...).
>
> If we switch the slf4j API scope to the `provider` from `compile` in the
> pom.xml, and then the users can use any version of slf4j.
>
> Unifying SLF4J is quite difficult, many libraries include the slf4j 1.x or
> 2.x, and when the slf4j version is inconsistent, we still need to use
> ``.
>
> Thanks,
> Zixuan
>
> Yunze Xu  于2024年4月27日周六 11:46写道：
>
> > The point is not related to how I should resolve the dependency issue.
> > It is how you care for the downstream users.
> >
> > Assuming there is an application that depends on pulsar-client 3.0.0
> > running well. Then after some days, maintainers tried upgrading the
> > pulsar-client to 3.3.0 and they found logs don't work. You tell them
> > to upgrade the slf4j bindings as well. It might generally be okay.
> > However, if they have developed their own slf4j binding for 1.7.x.
> > Now, they also have to change the code of their own slf4j binding. But
> > it could be a challenge because its own slf4j binding might also be
> > included on their other projects.
> >
> > Thanks,
> > Yunze
> >
> > On Sat, Apr 27, 2024 at 11:39 AM Yunze Xu  wrote:
> > >
> > > > we will encounter them sooner or later.
> > >
> > > I don't think so. As a logging facade, there is no convincing reason
> > > to keep it latest unless some CVEs.
> > >
> > > > so I used the `` to exclude the org.slf4j or
> > org.apache.logging.log4j, and so on.
> > >
> > > As I've mentioned before, things become complicated once your project
> > > is large. For example, the KSN project relies on the SLF4J from Pulsar
> > > implicitly because it expects the Pulsar dependency carries the SLF4J
> > > dependency.
> > >
> > > ```
> > > pulsar-broker
> > > pulsar-broker-auth-sasl
> > > pulsar-client-original
> > > pulsar-client-auth-sasl
> > > pulsar-common
> > > pulsar-client-admin-original
> > > ```
> > >
> > > I have to exclude the slf4j dependency for each `pulsar-*` dependency.
> > > Then import both the `slf4j-api` and `slf4j-log4j12` dependencies in
> > > the root pom.xml.
> > >
> > > ```
> > > 
> > >   
> > > org.slf4j
> > > slf4j-api
> > > ${slf4j.version}
> > >   
> > >
> > >   
> > > org.slf4j
> > > slf4j-log4j12
> > > ${slf4j.version}
> > > runtime
> > >   
> > > 
> > > ```
> > >
> > > And then it works, but it also shows how much changes are needed
> > > caused by such a PR in the upstream. Existing users might already
> > > depend on the carried slf4j dependency from Pulsar. The point is the
> > > upgrade could BREAK many existing downstream projects.
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Sat, Apr 27, 2024 at 1:21 AM Zixuan Liu  wrote:
> > > >
> > > > After upgrading to 2.0.13, some issues were exposed, and we will
> > encounter
> > >

Re: [DISCUSS] Restore the slf4j version to 1.7.x

[Yunze Xu]

The point is not related to how I should resolve the dependency issue.
It is how you care for the downstream users.

Assuming there is an application that depends on pulsar-client 3.0.0
running well. Then after some days, maintainers tried upgrading the
pulsar-client to 3.3.0 and they found logs don't work. You tell them
to upgrade the slf4j bindings as well. It might generally be okay.
However, if they have developed their own slf4j binding for 1.7.x.
Now, they also have to change the code of their own slf4j binding. But
it could be a challenge because its own slf4j binding might also be
included on their other projects.

Thanks,
Yunze

On Sat, Apr 27, 2024 at 11:39 AM Yunze Xu  wrote:
>
> > we will encounter them sooner or later.
>
> I don't think so. As a logging facade, there is no convincing reason
> to keep it latest unless some CVEs.
>
> > so I used the `` to exclude the org.slf4j or 
> > org.apache.logging.log4j, and so on.
>
> As I've mentioned before, things become complicated once your project
> is large. For example, the KSN project relies on the SLF4J from Pulsar
> implicitly because it expects the Pulsar dependency carries the SLF4J
> dependency.
>
> ```
> pulsar-broker
> pulsar-broker-auth-sasl
> pulsar-client-original
> pulsar-client-auth-sasl
> pulsar-common
> pulsar-client-admin-original
> ```
>
> I have to exclude the slf4j dependency for each `pulsar-*` dependency.
> Then import both the `slf4j-api` and `slf4j-log4j12` dependencies in
> the root pom.xml.
>
> ```
> 
>   
> org.slf4j
> slf4j-api
> ${slf4j.version}
>   
>
>   
> org.slf4j
> slf4j-log4j12
> ${slf4j.version}
> runtime
>   
> 
> ```
>
> And then it works, but it also shows how much changes are needed
> caused by such a PR in the upstream. Existing users might already
> depend on the carried slf4j dependency from Pulsar. The point is the
> upgrade could BREAK many existing downstream projects.
>
> Thanks,
> Yunze
>
> On Sat, Apr 27, 2024 at 1:21 AM Zixuan Liu  wrote:
> >
> > After upgrading to 2.0.13, some issues were exposed, and we will encounter
> > them sooner or later.
> >
> > When upgrading the slf4j in the pulsar, I also encountered the problem you
> > mentioned, so I used the `` to exclude the org.slf4j
> > or org.apache.logging.log4j, and so on.
> >
> > Do you think this approach is fair?
> >
> > Thanks,
> > Zixuan
> >
> > Yunze Xu  于2024年4月26日周五 20:41写道：
> >
> > > Hi all,
> > >
> > > Recently I upgraded my downstream project's dependency to the latest
> > > master branch and found no logs are printed now.
> > >
> > > ```
> > > SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> > > SLF4J: Defaulting to no-operation (NOP) logger implementation
> > > ```
> > >
> > > Finally I found it's caused by #22391 [1], which upgrades the
> > > slf4j-api version from 1.7.32 to 2.0.13. It's really a harmful change
> > > to downstream projects. For example, assuming there is a project that
> > > depends on the pulsar-client-all, it might adds a SLF4J binding
> > > dependency like:
> > >
> > > ```xml
> > >
> > > 
> > >   org.apache.pulsar
> > >   pulsar-client-all
> > >   3.2.2
> > > 
> > >
> > > 
> > >   org.slf4j
> > >   slf4j-simple
> > >   1.7.36
> > > 
> > > ```
> > >
> > > Yeah it works well. However, after upgrading the pulsar-client-all to
> > > the latest master, users have to upgrade the slf4j-simple to 2.0.13,
> > > otherwise the logging won't work.
> > >
> > > Things become worse when the downstream project is large. I tried
> > > adding the slf4j-simple or slf4j-reload4j 2.0.13 dependency to the
> > > protocol handler project that depends on pulsar-broker and none of
> > > them works. It has already wasted me much time debugging this logging
> > > issue. I'm really interested in what significant change that slf4j 2.x
> > > brings, except a higher version number that might make some developers
> > > think it's better?
> > >
> > > Therefore, I suggest reverting #22391 unless there is a significant
> > > advantage of slf4j 2.0.13.
> > >
> > > [1] https://github.com/apache/pulsar/pull/22391
> > >
> > > Thanks,
> > > Yunze
> > >

Re: [DISCUSS] Restore the slf4j version to 1.7.x

[Yunze Xu]

> we will encounter them sooner or later.

I don't think so. As a logging facade, there is no convincing reason
to keep it latest unless some CVEs.

> so I used the `` to exclude the org.slf4j or 
> org.apache.logging.log4j, and so on.

As I've mentioned before, things become complicated once your project
is large. For example, the KSN project relies on the SLF4J from Pulsar
implicitly because it expects the Pulsar dependency carries the SLF4J
dependency.

```
pulsar-broker
pulsar-broker-auth-sasl
pulsar-client-original
pulsar-client-auth-sasl
pulsar-common
pulsar-client-admin-original
```

I have to exclude the slf4j dependency for each `pulsar-*` dependency.
Then import both the `slf4j-api` and `slf4j-log4j12` dependencies in
the root pom.xml.

```

  
org.slf4j
slf4j-api
${slf4j.version}
  

  
org.slf4j
slf4j-log4j12
${slf4j.version}
runtime
  

```

And then it works, but it also shows how much changes are needed
caused by such a PR in the upstream. Existing users might already
depend on the carried slf4j dependency from Pulsar. The point is the
upgrade could BREAK many existing downstream projects.

Thanks,
Yunze

On Sat, Apr 27, 2024 at 1:21 AM Zixuan Liu  wrote:
>
> After upgrading to 2.0.13, some issues were exposed, and we will encounter
> them sooner or later.
>
> When upgrading the slf4j in the pulsar, I also encountered the problem you
> mentioned, so I used the `` to exclude the org.slf4j
> or org.apache.logging.log4j, and so on.
>
> Do you think this approach is fair?
>
> Thanks,
> Zixuan
>
> Yunze Xu  于2024年4月26日周五 20:41写道：
>
> > Hi all,
> >
> > Recently I upgraded my downstream project's dependency to the latest
> > master branch and found no logs are printed now.
> >
> > ```
> > SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> > SLF4J: Defaulting to no-operation (NOP) logger implementation
> > ```
> >
> > Finally I found it's caused by #22391 [1], which upgrades the
> > slf4j-api version from 1.7.32 to 2.0.13. It's really a harmful change
> > to downstream projects. For example, assuming there is a project that
> > depends on the pulsar-client-all, it might adds a SLF4J binding
> > dependency like:
> >
> > ```xml
> >
> > 
> >   org.apache.pulsar
> >   pulsar-client-all
> >   3.2.2
> > 
> >
> > 
> >   org.slf4j
> >   slf4j-simple
> >   1.7.36
> > 
> > ```
> >
> > Yeah it works well. However, after upgrading the pulsar-client-all to
> > the latest master, users have to upgrade the slf4j-simple to 2.0.13,
> > otherwise the logging won't work.
> >
> > Things become worse when the downstream project is large. I tried
> > adding the slf4j-simple or slf4j-reload4j 2.0.13 dependency to the
> > protocol handler project that depends on pulsar-broker and none of
> > them works. It has already wasted me much time debugging this logging
> > issue. I'm really interested in what significant change that slf4j 2.x
> > brings, except a higher version number that might make some developers
> > think it's better?
> >
> > Therefore, I suggest reverting #22391 unless there is a significant
> > advantage of slf4j 2.0.13.
> >
> > [1] https://github.com/apache/pulsar/pull/22391
> >
> > Thanks,
> > Yunze
> >

[DISCUSS] Restore the slf4j version to 1.7.x

[Yunze Xu]

Hi all,

Recently I upgraded my downstream project's dependency to the latest
master branch and found no logs are printed now.

```
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
```

Finally I found it's caused by #22391 [1], which upgrades the
slf4j-api version from 1.7.32 to 2.0.13. It's really a harmful change
to downstream projects. For example, assuming there is a project that
depends on the pulsar-client-all, it might adds a SLF4J binding
dependency like:

```xml


  org.apache.pulsar
  pulsar-client-all
  3.2.2



  org.slf4j
  slf4j-simple
  1.7.36

```

Yeah it works well. However, after upgrading the pulsar-client-all to
the latest master, users have to upgrade the slf4j-simple to 2.0.13,
otherwise the logging won't work.

Things become worse when the downstream project is large. I tried
adding the slf4j-simple or slf4j-reload4j 2.0.13 dependency to the
protocol handler project that depends on pulsar-broker and none of
them works. It has already wasted me much time debugging this logging
issue. I'm really interested in what significant change that slf4j 2.x
brings, except a higher version number that might make some developers
think it's better?

Therefore, I suggest reverting #22391 unless there is a significant
advantage of slf4j 2.0.13.

[1] https://github.com/apache/pulsar/pull/22391

Thanks,
Yunze

[ANNOUNCE] Apache Pulsar Client Python 3.5.0 released

[Yunze Xu]

The Apache Pulsar team is proud to announce Apache Pulsar Client
Python version 3.5.0.

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.

You can download the source code and the Python wheels in:
https://archive.apache.org/dist/pulsar/pulsar-client-python-3.5.0/

The Python wheels were uploaded to PyPI as well so that they can be
installed by `pip install pulsar-client==3.5.0`.

Release Notes are at:
https://pulsar.apache.org/release-notes/versioned/client-python-3.5.0/

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

Regards,

The Pulsar Team

Re: [VOTE] Pulsar Client Python Release 3.5.0 Candidate 3

[Yunze Xu]

Close this vote by 3 binding +1s

- Jiwei
- Yunze
- Zike

Thanks,
Yunze

On Fri, Apr 12, 2024 at 11:21 AM Zike Yang  wrote:
>
> +1 (binding)
>
> - Verified checksums and signatures
> - Installed Python client using the wheel file on macOS using Python
> 3.9/3.10 and ran the examples
> - Built from source on macOS and ran the example
>
> BR,
> Zike Yang
>
> On Thu, Apr 11, 2024 at 6:40 PM Yunze Xu  wrote:
> >
> > +1 (binding)
> >
> > - Verified signatures and checksums
> > - Built from source from source on macOS (with C++ client 3.5.1)
> > - Verified e2e with OAuth2 authentication for the following wheels:
> > - Verified e2e with 
> > pulsar_client-3.5.0-cp312-cp312-macosx_10_15_universal2.whl
> >
> > Thanks,
> > Yunze
> >
> > On Sun, Apr 7, 2024 at 11:16 PM guo jiwei  wrote:
> > >
> > > +1 (binding)
> > >
> > > - Checked the signature and checksums
> > > - Install the pulsar_client-3.5.0-cp310-cp310-macosx_10_15_universal2.whl
> > > - Run Pulsar standalone
> > > - Run the Python examples producer and consumer
> > >
> > >
> > > Regards
> > > Jiwei Guo (Tboy)
> > >
> > >
> > > On Tue, Apr 2, 2024 at 5:49 PM Yunze Xu  wrote:
> > >
> > > > This is the 3rd release candidate for Apache Pulsar Client Python,
> > > > version 3.5.0.
> > > >
> > > > It fixes the following issues:
> > > > https://github.com/apache/pulsar-client-python/milestone/6?closed=1
> > > >
> > > > *** Please download, test and vote on this release. This vote will
> > > > stay open for at least 72 hours ***
> > > >
> > > > Python wheels:
> > > >
> > > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.5.0-candidate-3/
> > > >
> > > > The supported python versions are 3.8, 3.9, 3.10, 3.11 and 3.12. The
> > > > supported platforms and architectures are:
> > > > - Windows x86_64 (windows/)
> > > > - glibc-based Linux x86_64 (linux-glibc-x86_64/)
> > > > - glibc-based Linux arm64 (linux-glibc-arm64/)
> > > > - musl-based Linux x86_64 (linux-musl-x86_64/)
> > > > - musl-based Linux arm64 (linux-musl-arm64/)
> > > > - macOS universal 2 (macos/)
> > > >
> > > > You can download the wheel (the `.whl` file) according to your own OS
> > > > and Python version
> > > > and install the wheel:
> > > > - Windows: `py -m pip install *.whl --force-reinstall`
> > > > - Linux or macOS: `python3 -m pip install *.whl --force-reinstall`
> > > >
> > > > The tag to be voted upon: v3.5.0-candidate-3
> > > > (38737a24f6ba77fe4efc5321980513ae317920e4)
> > > >
> > > > https://github.com/apache/pulsar-client-python/releases/tag/v3.5.0-candidate-3
> > > >
> > > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > > https://downloads.apache.org/pulsar/KEYS
> > > >
> > > > Please download the Python wheels and follow the README to test.
> > > >

Re: [VOTE] Pulsar Node.js Client Release 1.11.0 Candidate 3

[Yunze Xu]

+1 (binding)

- Verified signature and checksums
- Built from source on macOS
- Run e2e tests against a local standalone
- Run e2e tests with OAuth2 authentication against an online cluster

Thanks,
Yunze

On Tue, Apr 9, 2024 at 6:26 PM Baodi Shi  wrote:
>
> Hi everyone,
>
> This is the first release candidate for Apache Pulsar Node.js client,
> version 1.11.0.
>
> It fixes the following issues:
> - https://github.com/apache/pulsar-client-node/milestone/16?closed=1
> - Related cpp client issue:
> https://github.com/apache/pulsar-client-cpp/compare/v3.4.2...v3.5.1
>
> Please download the source files and review this release candidate:
> - Download the source package, verify shasum and asc
> - Follow the README.md to build and run the Pulsar Node.js client.
>
> The release candidate package has been published to the npm registry:
> https://www.npmjs.com/package/pulsar-client/v/1.11.0-rc.3
> You can install it by `npm i pulsar-client@1.11.0-rc.3
> --pulsar_binary_host_mirror=
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/` and
> verify the package.
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Source files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/pulsar-client-node-1.11.0-rc.3/
>
> Pulsar's KEYS file containing PGP keys we use to sign the release:
> https://downloads.apache.org/pulsar/KEYS
>
> SHA-512 checksum:
> 74196c05f80a0c2569c1d19d7e21ea18babb5fe75fc5936c6eef47574ee7a9abc0f4a7e4db3b740de760d477cb2dfc51c9fd5b2dd343ee54389d78b1e24849e7
> ./apache-pulsar-client-node-1.11.0.tar.gz
>
> The tag to be voted upon:
> v1.11.0-rc.3
> https://github.com/apache/pulsar-client-node/releases/tag/v1.11.0-rc.3
>
> Please review and vote on the release candidate #1 for the version 1.11.0,
> as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
>
> Thanks,
> Baodi Shi

Re: [VOTE] Pulsar Client Python Release 3.5.0 Candidate 3

[Yunze Xu]

+1 (binding)

- Verified signatures and checksums
- Built from source from source on macOS (with C++ client 3.5.1)
- Verified e2e with OAuth2 authentication for the following wheels:
- Verified e2e with pulsar_client-3.5.0-cp312-cp312-macosx_10_15_universal2.whl

Thanks,
Yunze

On Sun, Apr 7, 2024 at 11:16 PM guo jiwei  wrote:
>
> +1 (binding)
>
> - Checked the signature and checksums
> - Install the pulsar_client-3.5.0-cp310-cp310-macosx_10_15_universal2.whl
> - Run Pulsar standalone
> - Run the Python examples producer and consumer
>
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Tue, Apr 2, 2024 at 5:49 PM Yunze Xu  wrote:
>
> > This is the 3rd release candidate for Apache Pulsar Client Python,
> > version 3.5.0.
> >
> > It fixes the following issues:
> > https://github.com/apache/pulsar-client-python/milestone/6?closed=1
> >
> > *** Please download, test and vote on this release. This vote will
> > stay open for at least 72 hours ***
> >
> > Python wheels:
> >
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.5.0-candidate-3/
> >
> > The supported python versions are 3.8, 3.9, 3.10, 3.11 and 3.12. The
> > supported platforms and architectures are:
> > - Windows x86_64 (windows/)
> > - glibc-based Linux x86_64 (linux-glibc-x86_64/)
> > - glibc-based Linux arm64 (linux-glibc-arm64/)
> > - musl-based Linux x86_64 (linux-musl-x86_64/)
> > - musl-based Linux arm64 (linux-musl-arm64/)
> > - macOS universal 2 (macos/)
> >
> > You can download the wheel (the `.whl` file) according to your own OS
> > and Python version
> > and install the wheel:
> > - Windows: `py -m pip install *.whl --force-reinstall`
> > - Linux or macOS: `python3 -m pip install *.whl --force-reinstall`
> >
> > The tag to be voted upon: v3.5.0-candidate-3
> > (38737a24f6ba77fe4efc5321980513ae317920e4)
> >
> > https://github.com/apache/pulsar-client-python/releases/tag/v3.5.0-candidate-3
> >
> > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > https://downloads.apache.org/pulsar/KEYS
> >
> > Please download the Python wheels and follow the README to test.
> >

[VOTE] Pulsar Client Python Release 3.5.0 Candidate 3

[Yunze Xu]

This is the 3rd release candidate for Apache Pulsar Client Python,
version 3.5.0.

It fixes the following issues:
https://github.com/apache/pulsar-client-python/milestone/6?closed=1

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

Python wheels:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.5.0-candidate-3/

The supported python versions are 3.8, 3.9, 3.10, 3.11 and 3.12. The
supported platforms and architectures are:
- Windows x86_64 (windows/)
- glibc-based Linux x86_64 (linux-glibc-x86_64/)
- glibc-based Linux arm64 (linux-glibc-arm64/)
- musl-based Linux x86_64 (linux-musl-x86_64/)
- musl-based Linux arm64 (linux-musl-arm64/)
- macOS universal 2 (macos/)

You can download the wheel (the `.whl` file) according to your own OS
and Python version
and install the wheel:
- Windows: `py -m pip install *.whl --force-reinstall`
- Linux or macOS: `python3 -m pip install *.whl --force-reinstall`

The tag to be voted upon: v3.5.0-candidate-3
(38737a24f6ba77fe4efc5321980513ae317920e4)
https://github.com/apache/pulsar-client-python/releases/tag/v3.5.0-candidate-3

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

Please download the Python wheels and follow the README to test.

[ANNOUNCE] Apache Pulsar Client C++ 3.5.1 released

[Yunze Xu]

The Apache Pulsar team is proud to announce Apache Pulsar Client C++
version 3.5.1.

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/#pulsar-c-client

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

API documents are at:
https://pulsar.apache.org/api/cpp/3.5.x/index.html

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

Regards,

The Pulsar Team

Re: [VOTE] Pulsar Client C++ Release 3.5.1 Candidate 1

[Yunze Xu]

Closing with 3 binding +1s:
- Yunze
- Jiwei
- Penghui

and 1 non-binding +1:
- Baodi

Thanks,
Yunze

On Mon, Apr 1, 2024 at 1:23 PM PengHui Li  wrote:
>
> +1 (binding)
>
> - Verified the signatures
> - Built from source on macOS m2 pro
> - Ran the producer and consumer
>
> Regards,
> Penghui
>
> On Mon, Apr 1, 2024 at 9:45 AM guo jiwei  wrote:
>
> > +1 (binding)
> >
> > - Verified checksum and signatures
> > - Built from source on macOS m1
> > - Ran the tests
> >
> > Regards
> > Jiwei Guo (Tboy)
> >
> >
> > On Thu, Mar 28, 2024 at 10:38 PM Baodi Shi  wrote:
> >
> > > +1(non-binding)
> > >
> > > - Verified signature and checksums
> > > - build from macOS m1 local and run SampleProducer and SampleConsumer
> > >
> > >
> > > Thanks,
> > > Baodi Shi
> > >
> > >
> > > On Mar 28, 2024 at 20:44:33, Yunze Xu  wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > - Verified signature and checksums
> > > > - Built from source on macOS m1 with vcpkg
> > > > - Verified basic e2e case with a Pulsar standalone 3.2.0
> > > > - Verified Python client with this dependency:
> > > > https://github.com/apache/pulsar-client-python/pull/209
> > > > - Verified Node.js client with this dependency:
> > > > https://github.com/apache/pulsar-client-node/pull/370
> > > >
> > > > Thanks,
> > > > Yunze
> > > >
> > > > On Thu, Mar 28, 2024 at 4:42 PM Yunze Xu  wrote:
> > > >
> > > >
> > > > This is the first release candidate for Apache Pulsar Client C++,
> > version
> > > > 3.5.1.
> > > >
> > > >
> > > > It fixes the following issues:
> > > >
> > > > https://github.com/apache/pulsar-client-cpp/labels/release%2F3.5.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-client-cpp/pulsar-client-cpp-3.5.1-candidate-1/
> > > >
> > > >
> > > > SHA-512 checksums:
> > > >
> > > >
> > > >
> > >
> > d01ebd64292fb1e55b889f1e2c90821c5f7c04a84e109caccd442cb0b15e79701fe10adfcd33a28046db48e10598bb1405a9bb64c063f18378a6ee64b80da847
> > > >
> > > >  apache-pulsar-client-cpp-3.5.1.tar.gz
> > > >
> > > >
> > > > The tag to be voted upon:
> > > >
> > > > v3.5.1-candidate-1 (21f4a4cffefaa9391b79d79a7849da9c539af834)
> > > >
> > > >
> > >
> > https://github.com/apache/pulsar-client-cpp/releases/tag/v3.5.1-candidate-1
> > > >
> > > >
> > > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > >
> > > > https://downloads.apache.org/pulsar/KEYS
> > > >
> > > >
> > > > Please download the source package, and follow
> > > >
> > > >
> > > >
> > >
> > https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
> > > >
> > > > to compile and test.
> > > >
> > > >
> > > > Note: If you're going to run the unit tests locally, please make sure
> > > >
> > > > the proxy is disabled.
> > > >
> > > >
> > >
> >

Re: [DISCUSS] Plan for Pulsar Go Client 1.0.0

[Yunze Xu]

> This would lead to inconsistency in API definitions, making them
> appear disorganized.

I agree. Using such suffixes is really ugly and much harder to
maintain IMHO. It only makes people add APIs more casually. They might
think, oh, don't worry, if this API (e.g. doSomething()) does not make
sense in future, you can add another API with a suffix (e.g.
doSomethingInAnotherWay()).

Thanks,
Yunze

On Mon, Apr 1, 2024 at 8:05 PM Zike Yang  wrote:
>
> Thanks for all your comments. I address each one in line.
>
> > Regarding the `Close` method, I think it's exceptional. It's designed
> to return no error so that users can call `defer client.Close()` [1].
> To process errors in `Close()`, we can panic in the implementation and
> let users use `recover` to catch the panic.
>
> My initial idea was to implement the `io.Closer` interface to allow
> users to free up resources in a general way. After investigating this
> discussion: https://github.com/golang/go/issues/40483, I think that
> the close method for Pulsar resources should not return an error. The
> client should ensure all resources are released when closed,
> regardless of whether any error has occurred. So this makes sense to
> me.
>
> >  I’d add one more item for consideration: using WithX() methods instead of
> a strict for configurations:
> https://github.com/apache/pulsar-client-go/issues/68
>
> Thanks for sharing this issue. It makes sense to me.
>
> > We can add a method with context, so like: CloseWithContext.
> > We can still follow the above way, so like: CloseWithError.
>
> This would lead to inconsistency in API definitions, making them
> appear disorganized. For instance, some methods accept a context but
> don't end with "WithContext.". Same for the `WithError`. This also
> adds complexity to the API, resulting in a poor user experience.
> Moreover, we should actually deprecate the old APIs, which would make
> names like CloseWithCtx and FlushWithCtx seem odd.
>
> > In the ConsumerOptions, we use the `internal` package, this is incorrect,
> when you set the value for `BackoffPolicy`, you will see this error `Use of
> the internal package is not allowed`.
> For internal package, please see https://go.dev/doc/go1.4#internalpackages
>
> Yes. This issue https://github.com/apache/pulsar-client-go/issues/1187
> is actually tracking on it.
>
> > This will increase our maintenance times.
>
> We maintain two versions of the API, but they could share the same
> internal code. I don't think this will add much complexity. On the
> contrary, it would make our API maintenance clearer and easier. The
> approach mentioned above, using WithContext and WithError, is actually
> also increasing the maintenance workload.  I believe the complexity
> and workload it brings is not less than maintaining two versions, v1
> and v0, of our API.
>
> BR,
> Zike Yang
>
> On Sat, Mar 30, 2024 at 7:34 PM Zixuan Liu  wrote:
> >
> > I don't recommend breaking user APIs. There are many ways we can avoid it.
> >
> > > 1. We should support passing the context to some IO-related methods
> > like `Ack`, `Close`, `Flush`, etc, or any other methods. There is an
> > issue related to this discussion. [2]
> >
> > We can add a method with context, so like: CloseWithContext.
> >
> > > 2. Some methods need to return the error. Like `Reader.HasNext`,
> > `Close`. This is to adhere to Golang's error-handling standards.
> >
> > We can still follow the above way, so like: CloseWithError.
> >
> > > 4. Some APIs need to be refined and require introducing breaking
> > changes as they could affect user experience otherwise. For example,
> > this [4] is an issue discussing the redesign of the Backoff Policy
> > API.
> >
> > In the ConsumerOptions, we use the `internal` package, this is incorrect,
> > when you set the value for `BackoffPolicy`, you will see this error `Use of
> > the internal package is not allowed`.
> > For internal package, please see https://go.dev/doc/go1.4#internalpackages
> >
> > For incorrect implementation, we can fix this.
> >
> > > We can provide a separate package path for v1.x API versions,
> > maintaining v0.x and v1.x APIs separately.
> >
> > This will increase our maintenance times.
> >
> >
> > Matteo Merli  于2024年3月30日周六 13:08写道：
> >
> > > The plan looks great.
> > >
> > >  I’d add one more item for consideration: using WithX() methods instead of
> > > a strict for configurations:
> > > https://github.com/apache/pulsar-client-go/issues/68
> > >
> > >
> > > --
> > > Matteo Merli
> > > 
> > >
> > >
> > > On Fri, Mar 29, 2024 at 5:38 AM Zike Yang  wrote:
> > >
> > > > Hi, everyone
> > > >
> > > > The Pulsar Go Client[0] is now relatively mature. I've also noticed
> > > > that many people in the community have widely used it in their
> > > > production environments. However, there's still no official 1.0
> > > > version for the Go client. I would like to start a thread to discuss
> > > > the plan for releasing Go client 1.0.0.
> > > >
> > > > According to "Go Module 

Re: [DISCUSS] Plan for Pulsar Go Client 1.0.0

[Yunze Xu]

Regarding the `Close` method, I think it's exceptional. It's designed
to return no error so that users can call `defer client.Close()` [1].
To process errors in `Close()`, we can panic in the implementation and
let users use `recover` to catch the panic.

[1] https://github.com/apache/pulsar-client-go/pull/99

Thanks,
Yunze

On Fri, Mar 29, 2024 at 8:38 PM Zike Yang  wrote:
>
> Hi, everyone
>
> The Pulsar Go Client[0] is now relatively mature. I've also noticed
> that many people in the community have widely used it in their
> production environments. However, there's still no official 1.0
> version for the Go client. I would like to start a thread to discuss
> the plan for releasing Go client 1.0.0.
>
> According to "Go Module version numbering" [1], there are strict
> requirements for version management in Golang projects, which means we
> can't introduce any breaking changes within a major version. Before
> releasing version 1.0.0, we need to review our API and decide on the
> finalized API for Go client 1.0.0.
>
> I've observed that the current design of the Go client's API still has
> the following issues:
>
> 1. We should support passing the context to some IO-related methods
> like `Ack`, `Close`, `Flush`, etc, or any other methods. There is an
> issue related to this discussion. [2]
> 2. Some methods need to return the error. Like `Reader.HasNext`,
> `Close`. This is to adhere to Golang's error-handling standards.
> 3. We should expose errors to users so that users can inspect the
> types of errors returned. [3] is an issue to discuss about this.
> 4. Some APIs need to be refined and require introducing breaking
> changes as they could affect user experience otherwise. For example,
> this [4] is an issue discussing the redesign of the Backoff Policy
> API.
>
> Additionally, we need to continue standardizing the release process
> and fixing known issues:
> 1. Refine the changelog formt [5]. We could try to utilize the tool
> "go-changelog" [6] to generate the changelog automatically.
> 2. Refine the release process [7] to adhere the Golang Moduel version
> standard. We need to clearly define the compatibility relationships
> between different types of versions. Some processes may need to be
> adjusted to comply with these version standards.
>
> These API changes will inevitably introduce breaking changes. However,
> we do not want the release of Go client 1.0.0 to cause troublesome
> impacts on the upgrade process for all our existing users.
> Inspired by the blog "The Principles of Versioning in Go" [8], I
> believe we need to follow this principle in the process of releasing
> 1.0.0 and also for maintaining subsequent versions: We should strive
> to avoid introducing breaking changes to the existing APIs and
> behaviors. We aim to reduce the steps needed for users to upgrade to
> the major version.
>
> To achieve this, I would like to suggest the following basic solution:
>
> We can provide a separate package path for v1.x API versions,
> maintaining v0.x and v1.x APIs separately. At the same time, we will
> deprecate all v0.x APIs. For future major versions like 2.x, 3.x, we
> will follow this same approach according to Golang's standards. In
> this way, when users upgrade to 1.0.0, they can gradually modify their
> code to utilize the new version of API, while still being able to use
> the features of the old API. We will remove the v0.x API in a later
> version, perhaps in version 2.0.0.
>
> The structure for the v1 package would look like this:
> ├── go.mod# Note: The v0 APIs and v1 APIs will shared the same go.mod
> ├── v1
> │   └── pulsar
> │   └── client.go
> └── pulsar
>  └── client.go
>
> I did a small demo. You can check it here:
> https://github.com/RobertIndie/test-go [9].
>
> In this way, the user could still use `go get
> github.com/apache/pulsar-client-go@v1.0.0` to upgrade to the v1.0.0
> version. And use `import
> "github.com/apache/pulsar-client-go/v1/pulsar"` to use the new V1 API.
> And for the future major versions like v2.0.0. The users could use `go
> get github.com/apache/pulsar-client-go/v2` to install the client and
> use `import "github.com/apache/pulsar-client-go/v2/pulsar` to use the
> V2 API.
>
> While Golang's versioning standard allows us to introduce breaking
> changes to the v0.x API, I favor preserving the current API.
> Considering the resistance our users have towards upgrades, I am more
> inclined to avoid breaking changes to the existing API. This approach
> should reduce the impact of upgrades.
>
> For our next steps, we could proceed as follows:
> 1. Discuss and finalize the Go client version strategy to adhere to
> the "Golang Module version standard"[1]
> 2. Discuss and finalize the V1 API. We may need a PIP to finalize it.
> 3. Add the V1 API, develop the necessary features, and address issues
> based on this new API.
> 4. Release the Go Client 1.0.0 based on the refined release process.
>
> This is currently just a preliminary idea and plan 

Re: [VOTE] Pulsar Client C++ Release 3.5.1 Candidate 1

[Yunze Xu]

+1 (binding)

- Verified signature and checksums
- Built from source on macOS m1 with vcpkg
- Verified basic e2e case with a Pulsar standalone 3.2.0
- Verified Python client with this dependency:
https://github.com/apache/pulsar-client-python/pull/209
- Verified Node.js client with this dependency:
https://github.com/apache/pulsar-client-node/pull/370

Thanks,
Yunze

On Thu, Mar 28, 2024 at 4:42 PM Yunze Xu  wrote:
>
> This is the first release candidate for Apache Pulsar Client C++, version 
> 3.5.1.
>
> It fixes the following issues:
> https://github.com/apache/pulsar-client-cpp/labels/release%2F3.5.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-client-cpp/pulsar-client-cpp-3.5.1-candidate-1/
>
> SHA-512 checksums:
> d01ebd64292fb1e55b889f1e2c90821c5f7c04a84e109caccd442cb0b15e79701fe10adfcd33a28046db48e10598bb1405a9bb64c063f18378a6ee64b80da847
>  apache-pulsar-client-cpp-3.5.1.tar.gz
>
> The tag to be voted upon:
> v3.5.1-candidate-1 (21f4a4cffefaa9391b79d79a7849da9c539af834)
> https://github.com/apache/pulsar-client-cpp/releases/tag/v3.5.1-candidate-1
>
> Pulsar's KEYS file containing PGP keys you use to sign the release:
> https://downloads.apache.org/pulsar/KEYS
>
> Please download the source package, and follow
> https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
> to compile and test.
>
> Note: If you're going to run the unit tests locally, please make sure
> the proxy is disabled.

[VOTE] Pulsar Client C++ Release 3.5.1 Candidate 1

[Yunze Xu]

This is the first release candidate for Apache Pulsar Client C++, version 3.5.1.

It fixes the following issues:
https://github.com/apache/pulsar-client-cpp/labels/release%2F3.5.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-client-cpp/pulsar-client-cpp-3.5.1-candidate-1/

SHA-512 checksums:
d01ebd64292fb1e55b889f1e2c90821c5f7c04a84e109caccd442cb0b15e79701fe10adfcd33a28046db48e10598bb1405a9bb64c063f18378a6ee64b80da847
 apache-pulsar-client-cpp-3.5.1.tar.gz

The tag to be voted upon:
v3.5.1-candidate-1 (21f4a4cffefaa9391b79d79a7849da9c539af834)
https://github.com/apache/pulsar-client-cpp/releases/tag/v3.5.1-candidate-1

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

Please download the source package, and follow
https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
to compile and test.

Note: If you're going to run the unit tests locally, please make sure
the proxy is disabled.

[DISCUSS] Release Pulsar C++ Client 3.5.1 and upgrade the verify process

[Yunze Xu]

Hi all,

Recently I found a regression [1] for the C++ client 3.5.0 (thanks to
the reminder from @shibd). So I will push a fix and then release the
C++ client 3.5.1.

However, this is not the 1st time that a regression was introduced,
see [2] for example. So I suggest when verifying the C++ client, we
can verify the Python and Node.js clients by upgrading the
dependencies as well. See the updated release process in [3].

[1] https://github.com/apache/pulsar-client-cpp/issues/420
[2] https://lists.apache.org/thread/rjolgrlp4x1lmfj678k3hjco80kcb73c
[3] 
https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env#verify-the-3rd-party-projects-that-depend-on-pulsar-c-client

Thanks,
Yunze

Re: [VOTE] Pulsar Client Python Release 3.5.0 Candidate 2

[Yunze Xu]

Cancel this release for the regression found in
https://github.com/apache/pulsar-client-cpp/issues/420.

I will prepare the fix and start the release for the C++ client 3.5.1.
Then I will continue the candidate 3.

Thanks,
Yunze

On Mon, Mar 25, 2024 at 3:48 PM PengHui Li  wrote:
>
> +1 (binding)
>
> - Checked the signature
> - Installed the wheel on macOS with Python 3.12
> - Run the consume and produce examples
>
> Regards,
> Penghui
>
> On Fri, Mar 22, 2024 at 11:55 PM Yunze Xu  wrote:
>
> > This is the 2nd release candidate for Apache Pulsar Client Python,
> > version 3.5.0.
> >
> > It fixes the following issues:
> > https://github.com/apache/pulsar-client-python/milestone/6?closed=1
> >
> > *** Please download, test and vote on this release. This vote will
> > stay open for at least 72 hours ***
> >
> > Python wheels:
> >
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.5.0-candidate-2/
> >
> > The supported python versions are 3.8, 3.9, 3.10, 3.11 and 3.12. The
> > supported platforms and architectures are:
> > - Windows x86_64 (windows/)
> > - glibc-based Linux x86_64 (linux-glibc-x86_64/)
> > - glibc-based Linux arm64 (linux-glibc-arm64/)
> > - musl-based Linux x86_64 (linux-musl-x86_64/)
> > - musl-based Linux arm64 (linux-musl-arm64/)
> > - macOS universal 2 (macos/)
> >
> > You can download the wheel (the `.whl` file) according to your own OS
> > and Python version
> > and install the wheel:
> > - Windows: `py -m pip install *.whl --force-reinstall`
> > - Linux or macOS: `python3 -m pip install *.whl --force-reinstall`
> >
> > The tag to be voted upon: v3.5.0-candidate-2
> > (730c2d7dea60ff632688463662a6101cacb98c22)
> >
> > https://github.com/apache/pulsar-client-python/releases/tag/v3.5.0-candidate-2
> >
> > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > https://downloads.apache.org/pulsar/KEYS
> >
> > Please download the Python wheels and follow the README to test.
> >

[VOTE] Pulsar Client Python Release 3.5.0 Candidate 2

[Yunze Xu]

This is the 2nd release candidate for Apache Pulsar Client Python,
version 3.5.0.

It fixes the following issues:
https://github.com/apache/pulsar-client-python/milestone/6?closed=1

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

Python wheels:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.5.0-candidate-2/

The supported python versions are 3.8, 3.9, 3.10, 3.11 and 3.12. The
supported platforms and architectures are:
- Windows x86_64 (windows/)
- glibc-based Linux x86_64 (linux-glibc-x86_64/)
- glibc-based Linux arm64 (linux-glibc-arm64/)
- musl-based Linux x86_64 (linux-musl-x86_64/)
- musl-based Linux arm64 (linux-musl-arm64/)
- macOS universal 2 (macos/)

You can download the wheel (the `.whl` file) according to your own OS
and Python version
and install the wheel:
- Windows: `py -m pip install *.whl --force-reinstall`
- Linux or macOS: `python3 -m pip install *.whl --force-reinstall`

The tag to be voted upon: v3.5.0-candidate-2
(730c2d7dea60ff632688463662a6101cacb98c22)
https://github.com/apache/pulsar-client-python/releases/tag/v3.5.0-candidate-2

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

Please download the Python wheels and follow the README to test.

Re: [VOTE] Pulsar Client Python Release 3.5.0 Candidate 1

[Yunze Xu]

I will cancel this release since I want to add the same API
(`Consumer.get_name())` that is introduced in
https://github.com/apache/pulsar-client-cpp/pull/360.

Thanks,
Yunze

On Fri, Mar 22, 2024 at 2:28 PM Yunze Xu  wrote:
>
> This is the Nth release candidate for Apache Pulsar Client Python,
> version 3.5.0.
>
> It fixes the following issues:
> https://github.com/apache/pulsar-client-python/milestone/6?closed=1
>
> *** Please download, test and vote on this release. This vote will
> stay open for at least 72 hours ***
>
> Python wheels:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.5.0-candidate-1/
>
> The supported python versions are 3.8, 3.9, 3.10, 3.11 and 3.12. The
> supported platforms and architectures are:
> - Windows x86_64 (windows/)
> - glibc-based Linux x86_64 (linux-glibc-x86_64/)
> - glibc-based Linux arm64 (linux-glibc-arm64/)
> - musl-based Linux x86_64 (linux-musl-x86_64/)
> - musl-based Linux arm64 (linux-musl-arm64/)
> - macOS universal 2 (macos/)
>
> You can download the wheel (the `.whl` file) according to your own OS
> and Python version
> and install the wheel:
> - Windows: `py -m pip install *.whl --force-reinstall`
> - Linux or macOS: `python3 -m pip install *.whl --force-reinstall`
>
> The tag to be voted upon: v3.5.0-candidate-1
> (13c8c4e621737395d6b9648e2bf0150d66eedbe6)
> https://github.com/apache/pulsar-client-python/releases/tag/v3.5.0-candidate-1
>
> Pulsar's KEYS file containing PGP keys you use to sign the release:
> https://downloads.apache.org/pulsar/KEYS
>
> Please download the Python wheels and follow the README to test.

[VOTE] Pulsar Client Python Release 3.5.0 Candidate 1

[Yunze Xu]

This is the Nth release candidate for Apache Pulsar Client Python,
version 3.5.0.

It fixes the following issues:
https://github.com/apache/pulsar-client-python/milestone/6?closed=1

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

Python wheels:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.5.0-candidate-1/

The supported python versions are 3.8, 3.9, 3.10, 3.11 and 3.12. The
supported platforms and architectures are:
- Windows x86_64 (windows/)
- glibc-based Linux x86_64 (linux-glibc-x86_64/)
- glibc-based Linux arm64 (linux-glibc-arm64/)
- musl-based Linux x86_64 (linux-musl-x86_64/)
- musl-based Linux arm64 (linux-musl-arm64/)
- macOS universal 2 (macos/)

You can download the wheel (the `.whl` file) according to your own OS
and Python version
and install the wheel:
- Windows: `py -m pip install *.whl --force-reinstall`
- Linux or macOS: `python3 -m pip install *.whl --force-reinstall`

The tag to be voted upon: v3.5.0-candidate-1
(13c8c4e621737395d6b9648e2bf0150d66eedbe6)
https://github.com/apache/pulsar-client-python/releases/tag/v3.5.0-candidate-1

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

Please download the Python wheels and follow the README to test.

Re: [VOTE] PIP-344: Correct the behavior of the public API pulsarClient.getPartitionsForTopic(topicName)

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Wed, Mar 20, 2024 at 9:19 PM PengHui Li  wrote:
>
> +1 (binding)
>
> Regards.
> Penghui
>
> On Sat, Mar 16, 2024 at 6:28 AM Yubiao Feng
>  wrote:
>
> > Hi All
> >
> > This thread is to start a vote for PIP-344.
> >
> > PIP: https://github.com/apache/pulsar/pull/22182
> > Discussion thread:
> > https://lists.apache.org/thread/z693blcxoqk0mj0rzyt1k7nvy72j18t5
> >
> > Thanks
> > Yubiao Feng
> >

Re: [DISCUSS] Broken builds and CI Failures in Maintenance Branches; improving maintenance strategy to address root causes

[Yunze Xu]

> However, in async work, people should have more patience to read and write.

I mean, it would be better to have something like "TL; DR". Anyway,
I'd like to apply this change since the next feature release (3.3.0).

Thanks,
Yunze

On Tue, Mar 19, 2024 at 12:10 AM Lari Hotari  wrote:
>
> Thanks for the comments, Yunze.
>
> On 2024/03/18 05:48:39 Yunze Xu wrote:
> > I'm afraid many people don't have patience to read all the contents.
>
> I agree. However, in async work, people should have more patience to read and 
> write. Synchronous meetings aren't a good solution either. The lack of 
> patience could be caused by lack of interest. There's not a large group of 
> people in our community that are interested in improving the maintenance 
> strategy and also committed to invest their time and effort in these 
> activities. I hope more people sign up to this type of efforts and show their 
> interest and commitment in improving Apache Pulsar.
>
> > Here is my summary in short (please correct me if I'm wrong):
> > - For bug fixes, the target branch should be branch-3.0. Once the PR
> > is merged into branch-3.0, checkout the branch-3.x and run `git merge
> > branch-3.0` and resolve the conflicts
>
> I didn't describe the details of how this is handle. It is different in 
> practice.
>
> > - For features, the target branch should be branch-3.x
>
> New features would continue to go to master (or "main" if we decide to rename 
> it). Bugs would be fixed in the branch where the feature containing the bug 
> was introduced if it is missing from the LTS branch.
>
> > Since we introduced the LTS concept, I agree that we should make
> > branch-3.0 as the default branch. Cherry-picking is a disaster when
> > cherry-picks happen in the wrong order.
>
> Yes.
>
> -Lari
>
> On 2024/03/18 05:48:39 Yunze Xu wrote:
> > I'm afraid many people don't have patience to read all the contents.
> > Here is my summary in short (please correct me if I'm wrong):
> > - For bug fixes, the target branch should be branch-3.0. Once the PR
> > is merged into branch-3.0, checkout the branch-3.x and run `git merge
> > branch-3.0` and resolve the conflicts
> > - For features, the target branch should be branch-3.x
> >
> > Since we introduced the LTS concept, I agree that we should make
> > branch-3.0 as the default branch. Cherry-picking is a disaster when
> > cherry-picks happen in the wrong order.
> >
> >
> > Thanks,
> > Yunze
> >
> > On Tue, Mar 5, 2024 at 8:38 PM Lari Hotari  wrote:
> > >
> > > To enhance our maintenance processes, I've created a guide for
> > > configuring "git mergetool" to resolve merge conflicts:
> > >
> > > https://pulsar.apache.org/contribute/setup-mergetool/
> > >
> > > For Apache Pulsar core developers, managing git merge conflict
> > > resolution is a necessary task. To streamline this process, it's crucial
> > > to set up tools that aid in visualizing and resolving these conflicts.
> > >
> > > I encourage you to follow the guide to set up a git mergetool. Your
> > > feedback is valuable, and you're welcome to contribute improvements
> > > directly to the website. You can do this by creating a PR by editing
> > > https://github.com/apache/pulsar-site/edit/main/contribute/setup-mergetool.md
> > > directly in your browser.
> > >
> > > -Lari
> > >
> > > On 2024/03/01 14:01:55 Lari Hotari wrote:
> > > > Dear Pulsar Community,
> > > >
> > > > As we prepare for new releases in our maintenance branches, we have once
> > > > again encountered issues with our cherry-picking process. Some of our
> > > > maintenance branches are currently broken or were recently broken,
> > > > containing compilation errors or failing tests. Many have encountered
> > > > these issues, as we have seen new PRs come in to address the
> > > > problems. The compilation problems are already being addressed by
> > > > Heesung (release manager for 3.0.3) and myself. We aim to resolve these
> > > > issues as soon as possible. Please join #dev channel on Apache Pulsar
> > > > Slack to collaborate in real time to help with this and get updates.
> > > >
> > > > The cherry-picking process has always been problematic and lacks clear
> > > > documentation in Apache Pulsar. This often leads to our maintenance
> > > > branches breaking, especially as we approach release dates and begin
> > > > cherry-picking fixes. This recurring iss

Re: [DISCUSS] Clear definition for the APIs we should not remove or change simply

[Yunze Xu]

> I think that this is too broad. It would essentially prevent most 
> refactorings and improvements to Pulsar.

It makes sense. I will take some time to learn the use of japicmp.

Thanks,
Yunze

On Wed, Mar 20, 2024 at 8:59 PM Lari Hotari  wrote:
>
> On Wed, 20 Mar 2024 at 13:50, Yunze Xu  wrote:
> > Currently, there is no clear definition for the maintain strategy of
> > public APIs. To make it more clear, I mean "public interface methods"
> > and "public class methods" when I mentioned "public APIs".It's very
> > ambiguous if it's acceptable to modify the method signature. Here are
> > some examples:
> > - Public APIs in pulsar-broker or pulsar-broker-common could be used
> > in the protocol handlers
> > - Public APIs in pulsar-client could be used due to the lack of
> > control in pulsar-client-api like MessageId and PulsarClient
>
> Yes, there must be a clear definition of what are considered as stable APIs.
>
> There's already a solution in use for this purpose. For example, in
> ManagedCursor[1] there are annotations:
>
> @InterfaceAudience.LimitedPrivate
> @InterfaceStability.Stable
> public interface ManagedCursor {
>
> InterfaceAudience and InterfaceStability annotations are defined in
> BookKeeper [2].
>
> We should use tooling in CI to enforce binary compatibility of the
> stable APIs that shouldn't break.
>
> There's japicmp [3] that can be used to do this. japicmp comes with a
> maven plugin [4] that needs to be configured with the rules to be
> used. Without enforcement, the annotation solution isn't very effective.
>
> Flink's maven build uses japicmp for enforcing the rules [5]. They
> have a solution for updating the baseline when the API changes [6].
> That could be a good reference if we decide to adopt a similar
> solution for Pulsar.
>
> > For any existing public method, no matter if it's from an interface or a 
> > class,
> > - If it's in one module of pulsar-client-api, pulsar-common,
> > pulsar-broker-common, should not be modified until the next LTS
> > release (e.g. 4.0.0). Before that, it can only be marked as
> > deprecated.
>
> I think that this is too broad. It would essentially prevent most
> refactorings and improvements to Pulsar. We could choose to do so, but
> it has consequences.
> Each class should have a reason why it's part of the stable API. It
> shouldn't be too hard to list what is used by custom plugins and why.
> Custom plugin authors should provide this information and this could
> be taken into account when the stable API annotations are added and
> reviewed.
>
> > - Specifically, for patch releases (e.g. 3.2.1), it needs public
> > discussion in the mail list to be cherry-picked
>
> When the list of stable interfaces is minimal, there's a chance that
> those are kept stable and there wouldn't be a frequent reason to break
> APIs.
> When there's a clear reason to break an API, yes, the mailing list
> should be informed. When using a tool like japicmp, the change would
> need to be explicitly approved as part of the baseline to get the CI
> to pass. I just hope that we keep the stable API minimal and
> reasonable so that we don't end up in this situation very often.
>
> -Lari
>
> 1 - 
> https://github.com/apache/pulsar/blob/e81a20d667aef7c0f888e88dbcf972196012ebea/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/ManagedCursor.java#L45-L47
> 2 - 
> https://github.com/apache/bookkeeper/tree/master/bookkeeper-common/src/main/java/org/apache/bookkeeper/common/annotation
> 3 - https://siom79.github.io/japicmp/
> 4 - https://siom79.github.io/japicmp/MavenPlugin.html
> 5 - 
> https://github.com/apache/flink/blob/cb1d68e68a56b43720f631d4cc3636c97519bb65/pom.xml#L2329-L2400
> 6 - 
> https://github.com/apache/flink/blob/master/tools/releasing/update_japicmp_configuration.sh
>
> On Wed, 20 Mar 2024 at 13:50, Yunze Xu  wrote:
> >
> > Hi community,
> >
> > I'd like to bring back the discussion again since a similar discussion
> > happened long ago [1].
> >
> > Currently, there is no clear definition for the maintain strategy of
> > public APIs. To make it more clear, I mean "public interface methods"
> > and "public class methods" when I mentioned "public APIs".It's very
> > ambiguous if it's acceptable to modify the method signature. Here are
> > some examples:
> > - Public APIs in pulsar-broker or pulsar-broker-common could be used
> > in the protocol handlers
> > - Public APIs in pulsar-client could be used due to the lack of
> > control in pulsar-client-api like MessageId and PulsarClient
> >
> > However, we should

[DISCUSS] Clear definition for the APIs we should not remove or change simply

[Yunze Xu]

Hi community,

I'd like to bring back the discussion again since a similar discussion
happened long ago [1].

Currently, there is no clear definition for the maintain strategy of
public APIs. To make it more clear, I mean "public interface methods"
and "public class methods" when I mentioned "public APIs".It's very
ambiguous if it's acceptable to modify the method signature. Here are
some examples:
- Public APIs in pulsar-broker or pulsar-broker-common could be used
in the protocol handlers
- Public APIs in pulsar-client could be used due to the lack of
control in pulsar-client-api like MessageId and PulsarClient

However, we should not encourage users to leverage such APIs, which
are mostly used internally. If authors use these APIs, they should be
responsible to modify the code if a new release changed such APIs. See
concrete examples here [2].

Therefore, I suggest adding the API signature guarantee somewhere (as
a PIP or on the website). Here are my proposals.

For any existing public method, no matter if it's from an interface or a class,
- If it's in one module of pulsar-client-api, pulsar-common,
pulsar-broker-common, should not be modified until the next LTS
release (e.g. 4.0.0). Before that, it can only be marked as
deprecated.
- Otherwise, it can be modified in the next feature release (e.g. 3.3.0)
- Specifically, for patch releases (e.g. 3.2.1), it needs public
discussion in the mail list to be cherry-picked

The strategy above is more relaxed than my previous proposal [1]. It
tells ecosystem developers:
- What are the public APIs
- Use public APIs whenever possible
- It's okay to use internal APIs if existing public APIs cannot
satisfy their demands
- Propose new public APIs if they think their demands are universals
and then they won't risk modifying the code for new releases

[1] https://lists.apache.org/thread/87n22qskcnpb0x44bfjy1chgdxzh8tf9
[2] https://github.com/apache/pulsar/pull/22182#discussion_r1531754956

Thanks,
Yunze

[DISCUSS] Release Pulsar Python Client 3.5.0

[Yunze Xu]

Hi all,

I would like to propose releasing the Pulsar Python client 3.5.0.

It's over two months since the release of 3.4.0, and there are 16 new
commits: https://github.com/apache/pulsar-client-python/compare/v3.4.0...main.
The dependent C++ client was upgraded to 3.5.0 in
https://github.com/apache/pulsar-client-python/pull/202, which also
fixes some bugs. It's time to cut a new release.

Please let me know if you have any important fixes that need to be
included in Pulsar Python client 3.5.0.

Thanks,
Yunze

Re: [DISCUSS] Broken builds and CI Failures in Maintenance Branches; improving maintenance strategy to address root causes

[Yunze Xu]

I'm afraid many people don't have patience to read all the contents.
Here is my summary in short (please correct me if I'm wrong):
- For bug fixes, the target branch should be branch-3.0. Once the PR
is merged into branch-3.0, checkout the branch-3.x and run `git merge
branch-3.0` and resolve the conflicts
- For features, the target branch should be branch-3.x

Since we introduced the LTS concept, I agree that we should make
branch-3.0 as the default branch. Cherry-picking is a disaster when
cherry-picks happen in the wrong order.


Thanks,
Yunze

On Tue, Mar 5, 2024 at 8:38 PM Lari Hotari  wrote:
>
> To enhance our maintenance processes, I've created a guide for
> configuring "git mergetool" to resolve merge conflicts:
>
> https://pulsar.apache.org/contribute/setup-mergetool/
>
> For Apache Pulsar core developers, managing git merge conflict
> resolution is a necessary task. To streamline this process, it's crucial
> to set up tools that aid in visualizing and resolving these conflicts.
>
> I encourage you to follow the guide to set up a git mergetool. Your
> feedback is valuable, and you're welcome to contribute improvements
> directly to the website. You can do this by creating a PR by editing
> https://github.com/apache/pulsar-site/edit/main/contribute/setup-mergetool.md
> directly in your browser.
>
> -Lari
>
> On 2024/03/01 14:01:55 Lari Hotari wrote:
> > Dear Pulsar Community,
> >
> > As we prepare for new releases in our maintenance branches, we have once
> > again encountered issues with our cherry-picking process. Some of our
> > maintenance branches are currently broken or were recently broken,
> > containing compilation errors or failing tests. Many have encountered
> > these issues, as we have seen new PRs come in to address the
> > problems. The compilation problems are already being addressed by
> > Heesung (release manager for 3.0.3) and myself. We aim to resolve these
> > issues as soon as possible. Please join #dev channel on Apache Pulsar
> > Slack to collaborate in real time to help with this and get updates.
> >
> > The cherry-picking process has always been problematic and lacks clear
> > documentation in Apache Pulsar. This often leads to our maintenance
> > branches breaking, especially as we approach release dates and begin
> > cherry-picking fixes. This recurring issue has been the subject of
> > multiple discussions over the years. The "feature freeze" in the release
> > process does not mitigate the key problem with the cherry-picking
> > approach.
> >
> > Furthermore, the cherry-picking process is mostly based on tribal
> > knowledge and lacks clear documentation. I have previously expressed my
> > concerns about this on the mailing list in this thread:
> > https://lists.apache.org/thread/69mwjso51kzkrv5xgdmw04d9wngbg8br
> >
> > Many problems with cherry-picking arise because cherry-picks occur in
> > the wrong order, or dependent changes are not picked. Some dependent
> > changes shouldn't be picked since when we have made bug fixes in the
> > master branch, it can already contain changes for new features that
> > shouldn't be applied to maintenance branches. In those cases
> > a backport of the fix is needed and the original developer of the
> > PR might not be available to do this and there could be a significant
> > delay for the release if delivering the backport takes time.
> >
> > When cherry-picking and backporting is delegated to other developers,
> > in addition to delays, it can lead to coordination problems and commits
> > being picked and applied in an order that results in even more merge
> > conflicts. Thankfully, this isn't usually too painful, but it does
> > happen once in a while.
> >
> > A few days ago, I began working on improving the documentation of the
> > current process. I have added a section where I share some thoughts and
> > a tool to prevent future problems. You can find the document here:
> > https://pulsar.apache.org/contribute/release-process/#cherry-picking-changes-scheduled-for-the-release.
> > However, this does not fully describe the current process and will only
> > help to some extent.
> >
> > The added section should help prevent cherry-picking in the wrong order,
> > but it still has many gaps. Many developers do not have proper merge
> > conflict resolution tools configured. Without proper 3-way diff
> > visualization and merge tools, it's very difficult to resolve many of
> > the merge conflicts without making mistakes. This also requires a deep
> > understanding of the module where the conflicts occur.
> >
> > After we have made the next set of maintenance releases, I plan to
> > propose an alternative to the cherry-picking process that will address
> > the main issues that the Apache Pulsar project has been struggling with
> > every time we do releases.
> >
> > The alternative would be to designate the LTS branch as the default
> > branch, make bug fixes primarily in the LTS branch, merge fixes to newer
> > branches, and 

[ANNOUNCE] Apache Pulsar Client C++ 3.5.0 released

[Yunze Xu]

The Apache Pulsar team is proud to announce Apache Pulsar Client C++
version 3.5.0.

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/#pulsar-c-client

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

API documents are at:
https://pulsar.apache.org/api/cpp/3.5.x/index.html

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

Regards,

The Pulsar Team

Re: [VOTE] Pulsar Client C++ Release 3.5.0 Candidate 2

[Yunze Xu]

Close this vote by 3 binding +1s
- Yunze
- Penghui
- Jiwei

Thanks,
Yunze

On Fri, Mar 15, 2024 at 11:15 AM guo jiwei  wrote:
>
> +1 (binding)
>
> - Verified checksum and signatures
> - Built from source on macOS m1
> - Ran the tests
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Thu, Mar 14, 2024 at 9:12 PM Yunze Xu  wrote:
>
> > +1 (binding)
> >
> > - Verified checksum and signatures
> > - Built from source on macOS m1
> > - Upgrade the dependency of the python client and verified the issues
> > are fixed (https://github.com/apache/pulsar-client-python/pull/202)
> >
> > Thanks,
> > Yunze
> >
> > On Thu, Mar 14, 2024 at 6:13 PM Yunze Xu  wrote:
> > >
> > > The vcpkg submodule is just convenient for development. You can just
> > > run `git clone https://github.com/microsoft/vcpkg.git`
> > <https://github.com/microsoft/vcpkg.git> in the source
> > > directory instead of fetching the submodule.
> > >
> > > BTW, I just found that when INTEGRATE_VCPKG is ON, we cannot customize
> > > the CMAKE_TOOLCHAIN_FILE. So I opened a PR to fix it.
> > > https://github.com/apache/pulsar-client-cpp/pull/417
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Thu, Mar 14, 2024 at 3:47 PM Baodi Shi  wrote:
> > > >
> > > > Hi, yunze
> > > >
> > > >
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-cpp/pulsar-client-cpp-3.5.0-candidate-2/apache-pulsar-client-cpp-3.5.0.tar.gz
> > > > This source code not include vcpkg, If we unzip it and run the command
> > cmake
> > > > -B build -DINTEGRATE_VCPKG=ON, it throws an error. Do we need to
> > include
> > > > vcpkg in the source code?
> > > >
> > > >
> > > > Other passed verify:
> > > > -  Checked the sign and checksum
> > > > - Use macOS arm64 pre-built binaries to build node.js client
> > > >
> > > >
> > > >
> > > >
> > > > Thanks,
> > > > Baodi Shi
> > > >
> > > >
> > > > On Mar 12, 2024 at 10:25:56, Yunze Xu  wrote:
> > > >
> > > > > This is the second release candidate for Apache Pulsar Client C++,
> > > > > version 3.5.0.
> > > > >
> > > > > It fixes the following issues:
> > > > > https://github.com/apache/pulsar-client-cpp/milestone/6?closed=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-client-cpp/pulsar-client-cpp-3.5.0-candidate-2/
> > > > >
> > > > > SHA-512 checksums:
> > > > >
> > > > >
> > > > >
> > b590c7128a0110812e3a2f3b94f81078a3ff254709aab175265838fa45c4022f0fab83d4817c1d31883a68e49454c698d0ea7b858c4b7e8d756aa1f7f703fe12
> > > > > apache-pulsar-client-cpp-3.5.0.tar.gz
> > > > >
> > > > >
> > > > > The tag to be voted upon:
> > > > > v3.5.0-candidate-2 (916af95dda4d06162f9ea4e4180f9fd726c25a4e)
> > > > >
> > https://github.com/apache/pulsar-client-cpp/releases/tag/v3.5.0-candidate-2
> > > > >
> > > > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > > > https://downloads.apache.org/pulsar/KEYS
> > > > >
> > > > > Please download the source package, and follow
> > > > >
> > > > >
> > https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
> > > > > to compile and test.
> > > > >
> > > > > Note: If you're going to run the unit tests locally, please make sure
> > > > > the proxy is disabled.
> > > > >
> >

Re: [VOTE] Pulsar Client C++ Release 3.5.0 Candidate 2

[Yunze Xu]

+1 (binding)

- Verified checksum and signatures
- Built from source on macOS m1
- Upgrade the dependency of the python client and verified the issues
are fixed (https://github.com/apache/pulsar-client-python/pull/202)

Thanks,
Yunze

On Thu, Mar 14, 2024 at 6:13 PM Yunze Xu  wrote:
>
> The vcpkg submodule is just convenient for development. You can just
> run `git clone https://github.com/microsoft/vcpkg.git` in the source
> directory instead of fetching the submodule.
>
> BTW, I just found that when INTEGRATE_VCPKG is ON, we cannot customize
> the CMAKE_TOOLCHAIN_FILE. So I opened a PR to fix it.
> https://github.com/apache/pulsar-client-cpp/pull/417
>
> Thanks,
> Yunze
>
> On Thu, Mar 14, 2024 at 3:47 PM Baodi Shi  wrote:
> >
> > Hi, yunze
> >
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-cpp/pulsar-client-cpp-3.5.0-candidate-2/apache-pulsar-client-cpp-3.5.0.tar.gz
> > This source code not include vcpkg, If we unzip it and run the command cmake
> > -B build -DINTEGRATE_VCPKG=ON, it throws an error. Do we need to include
> > vcpkg in the source code?
> >
> >
> > Other passed verify:
> > -  Checked the sign and checksum
> > - Use macOS arm64 pre-built binaries to build node.js client
> >
> >
> >
> >
> > Thanks,
> > Baodi Shi
> >
> >
> > On Mar 12, 2024 at 10:25:56, Yunze Xu  wrote:
> >
> > > This is the second release candidate for Apache Pulsar Client C++,
> > > version 3.5.0.
> > >
> > > It fixes the following issues:
> > > https://github.com/apache/pulsar-client-cpp/milestone/6?closed=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-client-cpp/pulsar-client-cpp-3.5.0-candidate-2/
> > >
> > > SHA-512 checksums:
> > >
> > >
> > > b590c7128a0110812e3a2f3b94f81078a3ff254709aab175265838fa45c4022f0fab83d4817c1d31883a68e49454c698d0ea7b858c4b7e8d756aa1f7f703fe12
> > > apache-pulsar-client-cpp-3.5.0.tar.gz
> > >
> > >
> > > The tag to be voted upon:
> > > v3.5.0-candidate-2 (916af95dda4d06162f9ea4e4180f9fd726c25a4e)
> > > https://github.com/apache/pulsar-client-cpp/releases/tag/v3.5.0-candidate-2
> > >
> > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > https://downloads.apache.org/pulsar/KEYS
> > >
> > > Please download the source package, and follow
> > >
> > > https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
> > > to compile and test.
> > >
> > > Note: If you're going to run the unit tests locally, please make sure
> > > the proxy is disabled.
> > >

Re: [VOTE] Pulsar Client C++ Release 3.5.0 Candidate 2

[Yunze Xu]

The vcpkg submodule is just convenient for development. You can just
run `git clone https://github.com/microsoft/vcpkg.git` in the source
directory instead of fetching the submodule.

BTW, I just found that when INTEGRATE_VCPKG is ON, we cannot customize
the CMAKE_TOOLCHAIN_FILE. So I opened a PR to fix it.
https://github.com/apache/pulsar-client-cpp/pull/417

Thanks,
Yunze

On Thu, Mar 14, 2024 at 3:47 PM Baodi Shi  wrote:
>
> Hi, yunze
>
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-cpp/pulsar-client-cpp-3.5.0-candidate-2/apache-pulsar-client-cpp-3.5.0.tar.gz
> This source code not include vcpkg, If we unzip it and run the command cmake
> -B build -DINTEGRATE_VCPKG=ON, it throws an error. Do we need to include
> vcpkg in the source code?
>
>
> Other passed verify:
> -  Checked the sign and checksum
> - Use macOS arm64 pre-built binaries to build node.js client
>
>
>
>
> Thanks,
> Baodi Shi
>
>
> On Mar 12, 2024 at 10:25:56, Yunze Xu  wrote:
>
> > This is the second release candidate for Apache Pulsar Client C++,
> > version 3.5.0.
> >
> > It fixes the following issues:
> > https://github.com/apache/pulsar-client-cpp/milestone/6?closed=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-client-cpp/pulsar-client-cpp-3.5.0-candidate-2/
> >
> > SHA-512 checksums:
> >
> >
> > b590c7128a0110812e3a2f3b94f81078a3ff254709aab175265838fa45c4022f0fab83d4817c1d31883a68e49454c698d0ea7b858c4b7e8d756aa1f7f703fe12
> > apache-pulsar-client-cpp-3.5.0.tar.gz
> >
> >
> > The tag to be voted upon:
> > v3.5.0-candidate-2 (916af95dda4d06162f9ea4e4180f9fd726c25a4e)
> > https://github.com/apache/pulsar-client-cpp/releases/tag/v3.5.0-candidate-2
> >
> > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > https://downloads.apache.org/pulsar/KEYS
> >
> > Please download the source package, and follow
> >
> > https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
> > to compile and test.
> >
> > Note: If you're going to run the unit tests locally, please make sure
> > the proxy is disabled.
> >

[VOTE] Pulsar Client C++ Release 3.5.0 Candidate 2

[Yunze Xu]

This is the second release candidate for Apache Pulsar Client C++,
version 3.5.0.

It fixes the following issues:
https://github.com/apache/pulsar-client-cpp/milestone/6?closed=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-client-cpp/pulsar-client-cpp-3.5.0-candidate-2/

SHA-512 checksums:

b590c7128a0110812e3a2f3b94f81078a3ff254709aab175265838fa45c4022f0fab83d4817c1d31883a68e49454c698d0ea7b858c4b7e8d756aa1f7f703fe12
 apache-pulsar-client-cpp-3.5.0.tar.gz


The tag to be voted upon:
v3.5.0-candidate-2 (916af95dda4d06162f9ea4e4180f9fd726c25a4e)
https://github.com/apache/pulsar-client-cpp/releases/tag/v3.5.0-candidate-2

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

Please download the source package, and follow
https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
to compile and test.

Note: If you're going to run the unit tests locally, please make sure
the proxy is disabled.

Re: [VOTE] PIP-332: peek messages from topic subscription with offset value

[Yunze Xu]

+1 (binding)

The proposal overall LGTM. But since the PIP itself and its
implementation are coupled in the same PR, I left minor comments in
that PR directly, which does not affect my +1.

Thanks,
Yunze

On Mon, Mar 11, 2024 at 11:04 AM Yubiao Feng
 wrote:
>
> +1 (binding)
>
> Thanks
> Yubiao Feng
>
> On Tue, Mar 5, 2024 at 11:38 PM Balaji Lakshmanan 
> wrote:
>
> > Hi,
> >
> > This is the vote for the PIP-332 to peek messages from a topic subscription
> > with an offset value.
> >
> > Can you please reply with your vote?
> >
> > Here is the link to the PIP pull request
> > .
> >
> > Thanks,
> > Balaji
> >

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Yunze Xu]

My fault for missing the discussion mails for these PIPs because I
didn't check the archives of previous months.

Thanks,
Yunze

On Thu, Mar 7, 2024 at 3:05 PM Lari Hotari  wrote:
>
> On Thu, 7 Mar 2024 at 08:14, Girish Sharma  wrote:
> > There is for 310 -
> > https://lists.apache.org/thread/13ncst2nc311vxok1s75thl2gtnk7w1t
>
> Girish, thank you for sharing the link to the PIP-310 thread.
> We also met in community meetings to discuss PIP-310
> (https://lists.apache.org/thread/y1sqpyv37fo0k4bm1ox28wggvkb7pbtw).
>
> I believe PIP-310 is a successful example of excellent community 
> collaboration.
> With PIP-310, Girish provided insightful feedback and also presented a
> thorough analysis
> of the Pulsar Rate Limiters. As a first step, this led to PIP-322,
> Pulsar Rate Limiting Refactoring
> (https://github.com/apache/pulsar/blob/master/pip/pip-322.md). PIP-322
> has been implemented and delivered in Pulsar 3.2.0.
>
> There are also plans to continue the improvements with the next set of
> enhancements
> following PIP-322 (refer to:
> https://lists.apache.org/thread/rj14rmzd5z5sy7kfg22kt4l5dzjwk9vn)
> and to cover the original requirements behind PIP-310.
>
> I'm looking forward to continuing this collaboration to deliver
> further improvements to the
> existing multi-tenancy features. The areas of improvement are service
> level management
> and capacity management of a large Pulsar system. This is also a key concern 
> of
> messaging-as-a-service / streaming-as-a-service platform teams that
> build upon Apache Pulsar.
>
> -Lari

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Yunze Xu]

Regarding PIP-332 and PIP 310, similar to PIP-337, there is no
discussion mail in the dev mail list. David left a comment [1] in
PIP-332 and there is no response. We can see discussions among Lari,
Asaf and the author in PIP-310. And eventually PIP-310 is closed
because the author has a different way to go ahead [2].

How can you say it's simply ignored without discussion? But I can
confirm from those examples that
https://github.com/apache/pulsar/blob/master/pip/README.md is ignored
many times.

[1] https://github.com/apache/pulsar/pull/21927#issuecomment-1948954577
[2] https://github.com/apache/pulsar/pull/21399#issuecomment-1857889100

Thanks,
Yunze

On Thu, Mar 7, 2024 at 1:57 PM Yunze Xu  wrote:
>
> > Our team has also tried to submit multiple
> enhancements and also PIP, but most of them are bogged down by
> reviewers who are very new to Pulsar, might not understand messaging
> correctly, or don’t find such enhancements useful for their usecases.
>
> If  your PRs or PIPs are not taken enough care of, please show
> concrete examples and ping committers in GitHub, Slack or the mail
> list. If you're suspicious of the committers that blocked your
> contributions, you can also make the discussion open in the mail list
> for more visibility.
>
> You mentioned PIP-337 [1] as an example. Unfortunately, I see Lari
> left many comments 3 weeks ago and there are no responses. The author
> also does not send any mail to the dev mail list.
>
> Regarding the fact that SN's proposals get more focus. It's true and
> reasonable because many committers work for SN. If one wants to
> promote his proposal, he could ping others in the company. For non-SN
> contributors, they can also reach Pulsar committers in GitHub, Slack
> as I mentioned before.
>
> Let's take PIP-338 [2] as another example. I can tell you that my team
> (from SN) has tracked this proposal internally from the mail [3]
> though the priority is not high so we don't have much time to review
> it for now. And I see there are many discussions from Lari and Girish,
> while the author (Meet0861) only left 1 comment in these discussions.
> Anyway, I don't think it should be "simply ignored without
> discussion".
>
> [1] https://github.com/apache/pulsar/pull/22016
> [2] https://github.com/apache/pulsar/pull/22039
> [3] https://lists.apache.org/thread/0ythswmt6d0q10f1knctc7py0gh5s4rd
>
> Thanks,
> Yunze
>
>
> On Thu, Mar 7, 2024 at 11:23 AM Dave Fisher  wrote:
> >
> >
> >
> > > On Mar 6, 2024, at 10:01 PM, Kalwit S  wrote:
> > >
> > > Also, Pulsar may have
> > > numbers of non-SM PMC’s and committers, but if you look at the numbers 
> > > over
> > > the last 2-3 years, you’ll see that 99% are from SM.
> >
> > If you are saying that this is the proportion of new committers and PMC 
> > members in the last 2-3 years then 99% implies not a single non-SN 
> > committer and/or PMC member added. This statement is categorically 
> > incorrect and completely wrong. A number of individuals involved who are 
> > committers and PMC members have changed jobs during the course of their 
> > involvement. A surprising number have continued their involvement during 
> > their work transitions.
> >
> > > I can even cite a few examples from recent times from different users
> > > (PIP-337, PIP-338, PIP-332, PIP-310, etc) to illustrate how some
> > > improvements are simply ignored without discussion, some are without any
> > > conclusion, and some are not given the opportunity to be implemented, 
> > > which
> > > could have allowed other companies to implement a customized 
> > > implementation
> > > for their need based on plugged-in approach.
> >
> > You were asked to provide an example. You need to pick one PIP,  take the 
> > time to research the conversations, gather references (links) to emails, 
> > and explain how you think it is a problem. Be technical about just one. I 
> > promised to help investigate, but I won’t help if you won’t do anything to 
> > help us all understand.
> >
> >
> > > There are many examples
> > > (PIP-321) where it was developed by SN contributors, and while there is no
> > > consensus, they will still be a part of the system. Other PR examples show
> > > the same pattern, ignoring the needs of other companies, and merging the 
> > > PR
> > > of SN contributors on an immediate basis.
> >
> > You have not shown any pattern, you have merely asserted it is there. Your 
> > “unit test” is flawed. Do the work to factually prove your point.
> >
> > Thanks,
> > Dave
> >
> >
> >

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Yunze Xu]

> Our team has also tried to submit multiple
enhancements and also PIP, but most of them are bogged down by
reviewers who are very new to Pulsar, might not understand messaging
correctly, or don’t find such enhancements useful for their usecases.

If  your PRs or PIPs are not taken enough care of, please show
concrete examples and ping committers in GitHub, Slack or the mail
list. If you're suspicious of the committers that blocked your
contributions, you can also make the discussion open in the mail list
for more visibility.

You mentioned PIP-337 [1] as an example. Unfortunately, I see Lari
left many comments 3 weeks ago and there are no responses. The author
also does not send any mail to the dev mail list.

Regarding the fact that SN's proposals get more focus. It's true and
reasonable because many committers work for SN. If one wants to
promote his proposal, he could ping others in the company. For non-SN
contributors, they can also reach Pulsar committers in GitHub, Slack
as I mentioned before.

Let's take PIP-338 [2] as another example. I can tell you that my team
(from SN) has tracked this proposal internally from the mail [3]
though the priority is not high so we don't have much time to review
it for now. And I see there are many discussions from Lari and Girish,
while the author (Meet0861) only left 1 comment in these discussions.
Anyway, I don't think it should be "simply ignored without
discussion".

[1] https://github.com/apache/pulsar/pull/22016
[2] https://github.com/apache/pulsar/pull/22039
[3] https://lists.apache.org/thread/0ythswmt6d0q10f1knctc7py0gh5s4rd

Thanks,
Yunze


On Thu, Mar 7, 2024 at 11:23 AM Dave Fisher  wrote:
>
>
>
> > On Mar 6, 2024, at 10:01 PM, Kalwit S  wrote:
> >
> > Also, Pulsar may have
> > numbers of non-SM PMC’s and committers, but if you look at the numbers over
> > the last 2-3 years, you’ll see that 99% are from SM.
>
> If you are saying that this is the proportion of new committers and PMC 
> members in the last 2-3 years then 99% implies not a single non-SN committer 
> and/or PMC member added. This statement is categorically incorrect and 
> completely wrong. A number of individuals involved who are committers and PMC 
> members have changed jobs during the course of their involvement. A 
> surprising number have continued their involvement during their work 
> transitions.
>
> > I can even cite a few examples from recent times from different users
> > (PIP-337, PIP-338, PIP-332, PIP-310, etc) to illustrate how some
> > improvements are simply ignored without discussion, some are without any
> > conclusion, and some are not given the opportunity to be implemented, which
> > could have allowed other companies to implement a customized implementation
> > for their need based on plugged-in approach.
>
> You were asked to provide an example. You need to pick one PIP,  take the 
> time to research the conversations, gather references (links) to emails, and 
> explain how you think it is a problem. Be technical about just one. I 
> promised to help investigate, but I won’t help if you won’t do anything to 
> help us all understand.
>
>
> > There are many examples
> > (PIP-321) where it was developed by SN contributors, and while there is no
> > consensus, they will still be a part of the system. Other PR examples show
> > the same pattern, ignoring the needs of other companies, and merging the PR
> > of SN contributors on an immediate basis.
>
> You have not shown any pattern, you have merely asserted it is there. Your 
> “unit test” is flawed. Do the work to factually prove your point.
>
> Thanks,
> Dave
>
>
>

Re: [VOTE] Pulsar Client Go Release 0.12.1 Candidate 1

[Yunze Xu]

+1 (binding)

- Verified checksum and signatures
- Run OAuth2 e2e examples with 0.12.1-candidate-1
- Built from source and run perf to produce and consume

Thanks,
Yunze

On Thu, Feb 29, 2024 at 11:05 AM Zike Yang  wrote:
>
> Hi everyone,
> Please review and vote on the release candidate #1 for the version
> 0.12.1, as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
> This is the first release candidate for Apache Pulsar Go client, version 
> 0.12.1.
>
> The release note/changelog for Go client 0.12.1:
> https://github.com/apache/pulsar-client-go/pull/1189/files
>
> Pulsar Client Go's KEYS file contains PGP keys we used to sign this release:
> https://downloads.apache.org/pulsar/KEYS
>
> Please download these packages and review this release candidate:
> - Review release notes: https://github.com/apache/pulsar-client-go/pull/1189
> - Download the source package (verify shasum, and asc) and follow the
> README.md to build and run the pulsar-client-go.
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Source file:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.12.1-candidate-1/
>
> The tag to be voted upon:
> v0.12.1-candidate-1
> https://github.com/apache/pulsar-client-go/tree/v0.12.1-candidate-1
>
> SHA-512 checksums:
> 691a301d099a602baa30bb7ec22dc33b8503d5ad5aa5fe43f51aab188099e4781844070de11584fd82d40227a28fe763ed8bd2cfa93b99d73ebfd34c6061e02d
>  apache-pulsar-client-go-0.12.1-src.tar.gz

Re: [VOTE] Pulsar Client C++ Release 3.5.0 Candidate 1

[Yunze Xu]

Cancel this vote since I want to include the fix to
https://github.com/apache/pulsar-client-python/issues/199 in this
release.

Thanks,
Yunze

On Fri, Mar 1, 2024 at 2:40 PM Yunze Xu  wrote:
>
> This is the first release candidate for Apache Pulsar Client C++, version 
> 3.5.0.
>
> It fixes the following issues:
> https://github.com/apache/pulsar-client-cpp/milestone/6?closed=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-client-cpp/pulsar-client-cpp-3.5.0-candidate-1/
>
> SHA-512 checksums:
>
> d13640bf407f48e94aac3cf62591d1295726a28a14f38e90ca6c520252d4489512e237b4e2888747e0199b1f54a782a0b6baa3f2c9b6464f6970a9a1d6d1af0f
>  apache-pulsar-client-cpp-3.5.0.tar.gz
>
>
> The tag to be voted upon:
> v3.5.0-candidate-1 (3b574c739e6a62696e0bf2374ab43e7f0b24b377)
> https://github.com/apache/pulsar-client-cpp/releases/tag/v3.5.0-candidate-1
>
> Pulsar's KEYS file containing PGP keys you use to sign the release:
> https://downloads.apache.org/pulsar/KEYS
>
> Please download the source package, and follow
> https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
> to compile and test.
>
> Note: If you're going to run the unit tests locally, please make sure
> the proxy is disabled.

[VOTE] Pulsar Client C++ Release 3.5.0 Candidate 1

[Yunze Xu]

This is the first release candidate for Apache Pulsar Client C++, version 3.5.0.

It fixes the following issues:
https://github.com/apache/pulsar-client-cpp/milestone/6?closed=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-client-cpp/pulsar-client-cpp-3.5.0-candidate-1/

SHA-512 checksums:

d13640bf407f48e94aac3cf62591d1295726a28a14f38e90ca6c520252d4489512e237b4e2888747e0199b1f54a782a0b6baa3f2c9b6464f6970a9a1d6d1af0f
 apache-pulsar-client-cpp-3.5.0.tar.gz


The tag to be voted upon:
v3.5.0-candidate-1 (3b574c739e6a62696e0bf2374ab43e7f0b24b377)
https://github.com/apache/pulsar-client-cpp/releases/tag/v3.5.0-candidate-1

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

Please download the source package, and follow
https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
to compile and test.

Note: If you're going to run the unit tests locally, please make sure
the proxy is disabled.

[Discuss] Release Pulsar C++ Client 3.5.0

[Yunze Xu]

I would like to propose releasing the Pulsar C++ Client 3.5.0.

It has been about 2 months since the last release (3.4.2). There have
been many new features and bug fixes since then. It's time to release
a new version. I will start the release once
https://github.com/apache/pulsar-client-cpp/pull/401 is ready.

Please let me know if you have any PRs that need to be included in 3.5.0.

Thanks,
Yunze

Re: [VOTE] Pulsar Release 3.2.0 Candidate 5

[Yunze Xu]

I changed my binding -1 to +0 now.

This behavior change is implicit but acceptable. The previous way of
setting up standalone should be wrong but it just accidentally works.
When system topic policy is enabled, the `brokerClientXxx` arguments
must be configured correctly to ensure the system topic policies can
be loaded or updated. To disable this limitation, we should disable
the system topic policy, while it's enabled by default since 2.11 [1].

[1] https://github.com/apache/pulsar/pull/15619

Thanks,
Yunze

On Fri, Feb 2, 2024 at 9:45 PM Yunze Xu  wrote:
>
> I pushed a fix: https://github.com/apache/pulsar/pull/22014
>
> Thanks,
> Yunze
>
> On Fri, Feb 2, 2024 at 9:15 PM Yunze Xu  wrote:
> >
> > Yes. I wrote a unit test in Java [1]. This breaking change is
> > introduced by #21445 [2], which requires the topic policies to be
> > available in `BrokerTopic#getTopic`.
> >
> > However, when the built-in client is not configured correctly, e.g.
> > `brokerClientXxx` authentication arguments are not configured
> > correctly, `BrokerService#getTopicPoliciesBypassSystemTopic` will
> > always fail, which makes `BrokerService#getTopic` fail.
> >
> > [1] 
> > https://github.com/BewareMyPower/pulsar/commit/eab7002299764765ef43f7d6d63a4bd993bba9c0
> > [2] https://github.com/apache/pulsar/pull/21445
> >
> > Thanks,
> > Yunze
> >
> > On Fri, Feb 2, 2024 at 8:41 PM PengHui Li  wrote:
> > >
> > > It looks like some tests are missed in the Java client?
> > > Otherwise, the java client detected this break change.
> > >
> > > Thanks,
> > > Penghui
> > >
> > > On Fri, Feb 2, 2024 at 11:40 AM Yunze Xu  wrote:
> > >
> > > > -1 (binding)
> > > >
> > > > I observed a regression for Pulsar 3.1.2 recently because the latest
> > > > image was just updated yesterday [1]. It seems related to the SSL
> > > > hostname verification because the failed tests come from
> > > > https://github.com/apache/pulsar-client-cpp/pull/126. I tested the
> > > > `technoboy8/pulsar:3.2.0-8025763` image locally and found the tests
> > > > still failed. You can also check the CI test result [2].
> > > >
> > > > Currently, I'm debugging locally to see why the tests failed. Before
> > > > figuring it out, we should prevent this release.
> > > >
> > > > [1]
> > > > https://github.com/apache/pulsar-client-cpp/pull/392#issuecomment-1922698516
> > > > [2] https://github.com/apache/pulsar-client-cpp/pull/394
> > > >
> > > > Thanks,
> > > > Yunze
> > > >
> > > > On Thu, Feb 1, 2024 at 8:57 AM PengHui Li  wrote:
> > > > >
> > > > > +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 Wed, Jan 31, 2024 at 11:40 PM guo jiwei  
> > > > > wrote:
> > > > >
> > > > > > This is the fifth 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 vote will
> > > > stay
> > > > > > open for at least 72 hours ***
> > > > > >
> > > > > > 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-5/
> > > > > >
> > > > > > SHA-512 checksums:
> > > > > >
> > > > > >
> > > > > >
> > > > 194b3a4d51b972ec58c8f2ae4ccaadb3cac229984ea5e7e8a396a1210d4b3adde83ab30ef31c9aa384942f81959da91ab250f5689cd010b4ae71a2b10956af2c
> > > > > >
> > > > > > apache-pulsar-3.2.0-bin.tar.gz
> > > > > >
> > > > > >
> >

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

[Yunze Xu]

Hi Dave,

> This would be a commitment by the Pulsar PMC to support third party code.

Well. I think you mean the third party code from StreamNative is not
as reliable as etcd or RocksDB. I agree. The current problem is that
the MetadataStore is not pluggable. What if a personal contributor
contributes a metadata store to an external metadata store system?
What commitment should be made? Or do you intend to reject the
proposal because it's not reliable because he might not maintain the
external metadata store anymore?

Thanks,
Yunze

On Sun, Feb 4, 2024 at 3:23 AM Dave Fisher  wrote:
>
> Hi -
>
> What? A cascade of agreement without questions? Seems like this has been 
> discussed elsewhere?
>
> I have concerns since with this PIP we are making changes to support a third 
> party library.
>
> 1. Have people read the PIP text? I see some typos which could be fixed. 
> Simple things nothing objectionable.
>
> 2. This would be a commitment by the Pulsar PMC to support third party code. 
> What commitment is there by StreamNative to keep the two Oxia repositories 
> open source? Relevant because I’ve heard that some StreamNative protocol 
> handlers have been archived. I know it’s not completely analogous, but if we 
> are making changes to Pulsar then an explicit commitment is best.
>
> Best,
> Dave
>
> > On Jan 31, 2024, at 3:57 PM, Matteo Merli  wrote:
> >
> > https://github.com/apache/pulsar/pull/22009
> >
> > ===
> >
> > # PIP-335: Supporty 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 a 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: [VOTE] Pulsar Release 3.2.0 Candidate 5

[Yunze Xu]

I pushed a fix: https://github.com/apache/pulsar/pull/22014

Thanks,
Yunze

On Fri, Feb 2, 2024 at 9:15 PM Yunze Xu  wrote:
>
> Yes. I wrote a unit test in Java [1]. This breaking change is
> introduced by #21445 [2], which requires the topic policies to be
> available in `BrokerTopic#getTopic`.
>
> However, when the built-in client is not configured correctly, e.g.
> `brokerClientXxx` authentication arguments are not configured
> correctly, `BrokerService#getTopicPoliciesBypassSystemTopic` will
> always fail, which makes `BrokerService#getTopic` fail.
>
> [1] 
> https://github.com/BewareMyPower/pulsar/commit/eab7002299764765ef43f7d6d63a4bd993bba9c0
> [2] https://github.com/apache/pulsar/pull/21445
>
> Thanks,
> Yunze
>
> On Fri, Feb 2, 2024 at 8:41 PM PengHui Li  wrote:
> >
> > It looks like some tests are missed in the Java client?
> > Otherwise, the java client detected this break change.
> >
> > Thanks,
> > Penghui
> >
> > On Fri, Feb 2, 2024 at 11:40 AM Yunze Xu  wrote:
> >
> > > -1 (binding)
> > >
> > > I observed a regression for Pulsar 3.1.2 recently because the latest
> > > image was just updated yesterday [1]. It seems related to the SSL
> > > hostname verification because the failed tests come from
> > > https://github.com/apache/pulsar-client-cpp/pull/126. I tested the
> > > `technoboy8/pulsar:3.2.0-8025763` image locally and found the tests
> > > still failed. You can also check the CI test result [2].
> > >
> > > Currently, I'm debugging locally to see why the tests failed. Before
> > > figuring it out, we should prevent this release.
> > >
> > > [1]
> > > https://github.com/apache/pulsar-client-cpp/pull/392#issuecomment-1922698516
> > > [2] https://github.com/apache/pulsar-client-cpp/pull/394
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Thu, Feb 1, 2024 at 8:57 AM PengHui Li  wrote:
> > > >
> > > > +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 Wed, Jan 31, 2024 at 11:40 PM guo jiwei  wrote:
> > > >
> > > > > This is the fifth 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 vote will
> > > stay
> > > > > open for at least 72 hours ***
> > > > >
> > > > > 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-5/
> > > > >
> > > > > SHA-512 checksums:
> > > > >
> > > > >
> > > > >
> > > 194b3a4d51b972ec58c8f2ae4ccaadb3cac229984ea5e7e8a396a1210d4b3adde83ab30ef31c9aa384942f81959da91ab250f5689cd010b4ae71a2b10956af2c
> > > > >
> > > > > apache-pulsar-3.2.0-bin.tar.gz
> > > > >
> > > > >
> > > > >
> > > 7248f2566627d772093204a61ae2ea87b58dd18f374d2fd624827eb95f4102bfe07b2be87a4e7b6c7c296c5791af623f308885bfbe89069d10620f9da73ded93
> > > > >
> > > > > apache-pulsar-3.2.0-src.tar.gz
> > > > >
> > > > > Maven staging repo:
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachepulsar-1265/
> > > > >
> > > > > The tag to verify:
> > > > > v3.2.0-candidate-5 (802576372132617b5076a44004846f2dbabede08)
> > > > > https://github.com/apache/pulsar/commits/v3.2.0-candidate-5/
> > > > >
> > > > > 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-8025763/images/sha256-4666cc754439a2e6844569bb500365ded382b81d8fc9d4552e3c435702b59d86?context=repo
> > > > > <
> > > > >
> > > https://hub.docker.com/layers/mattison/pulsar/3.1.0-candidate-1/images/sha256-0efbaad7d893cc5041a46a2d4d56432bda855ae4068a38349777d1be6e98d27d?context=explore
> > > > > >
> > > > > pulsar-all images:
> > > > >
> > > > >
> > > https://hub.docker.com/layers/technoboy8/pulsar-all/3.2.0-8025763/images/sha256-b308fd819298bb2badc20ecd86547c43a7c8652aebd716816c7f8f24dbb1b34e?context=repo
> > > > >
> > > > > Please download the source package, and follow the README to build
> > > > > and run the Pulsar standalone service.
> > > > >
> > > > >
> > > > >
> > > > > Regards
> > > > > Jiwei Guo (Tboy)
> > > > >
> > >

Re: [VOTE] Pulsar Release 3.2.0 Candidate 5

[Yunze Xu]

Yes. I wrote a unit test in Java [1]. This breaking change is
introduced by #21445 [2], which requires the topic policies to be
available in `BrokerTopic#getTopic`.

However, when the built-in client is not configured correctly, e.g.
`brokerClientXxx` authentication arguments are not configured
correctly, `BrokerService#getTopicPoliciesBypassSystemTopic` will
always fail, which makes `BrokerService#getTopic` fail.

[1] 
https://github.com/BewareMyPower/pulsar/commit/eab7002299764765ef43f7d6d63a4bd993bba9c0
[2] https://github.com/apache/pulsar/pull/21445

Thanks,
Yunze

On Fri, Feb 2, 2024 at 8:41 PM PengHui Li  wrote:
>
> It looks like some tests are missed in the Java client?
> Otherwise, the java client detected this break change.
>
> Thanks,
> Penghui
>
> On Fri, Feb 2, 2024 at 11:40 AM Yunze Xu  wrote:
>
> > -1 (binding)
> >
> > I observed a regression for Pulsar 3.1.2 recently because the latest
> > image was just updated yesterday [1]. It seems related to the SSL
> > hostname verification because the failed tests come from
> > https://github.com/apache/pulsar-client-cpp/pull/126. I tested the
> > `technoboy8/pulsar:3.2.0-8025763` image locally and found the tests
> > still failed. You can also check the CI test result [2].
> >
> > Currently, I'm debugging locally to see why the tests failed. Before
> > figuring it out, we should prevent this release.
> >
> > [1]
> > https://github.com/apache/pulsar-client-cpp/pull/392#issuecomment-1922698516
> > [2] https://github.com/apache/pulsar-client-cpp/pull/394
> >
> > Thanks,
> > Yunze
> >
> > On Thu, Feb 1, 2024 at 8:57 AM PengHui Li  wrote:
> > >
> > > +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 Wed, Jan 31, 2024 at 11:40 PM guo jiwei  wrote:
> > >
> > > > This is the fifth 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 vote will
> > stay
> > > > open for at least 72 hours ***
> > > >
> > > > 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-5/
> > > >
> > > > SHA-512 checksums:
> > > >
> > > >
> > > >
> > 194b3a4d51b972ec58c8f2ae4ccaadb3cac229984ea5e7e8a396a1210d4b3adde83ab30ef31c9aa384942f81959da91ab250f5689cd010b4ae71a2b10956af2c
> > > >
> > > > apache-pulsar-3.2.0-bin.tar.gz
> > > >
> > > >
> > > >
> > 7248f2566627d772093204a61ae2ea87b58dd18f374d2fd624827eb95f4102bfe07b2be87a4e7b6c7c296c5791af623f308885bfbe89069d10620f9da73ded93
> > > >
> > > > apache-pulsar-3.2.0-src.tar.gz
> > > >
> > > > Maven staging repo:
> > > >
> > https://repository.apache.org/content/repositories/orgapachepulsar-1265/
> > > >
> > > > The tag to verify:
> > > > v3.2.0-candidate-5 (802576372132617b5076a44004846f2dbabede08)
> > > > https://github.com/apache/pulsar/commits/v3.2.0-candidate-5/
> > > >
> > > > 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-8025763/images/sha256-4666cc754439a2e6844569bb500365ded382b81d8fc9d4552e3c435702b59d86?context=repo
> > > > <
> > > >
> > https://hub.docker.com/layers/mattison/pulsar/3.1.0-candidate-1/images/sha256-0efbaad7d893cc5041a46a2d4d56432bda855ae4068a38349777d1be6e98d27d?context=explore
> > > > >
> > > > pulsar-all images:
> > > >
> > > >
> > https://hub.docker.com/layers/technoboy8/pulsar-all/3.2.0-8025763/images/sha256-b308fd819298bb2badc20ecd86547c43a7c8652aebd716816c7f8f24dbb1b34e?context=repo
> > > >
> > > > Please download the source package, and follow the README to build
> > > > and run the Pulsar standalone service.
> > > >
> > > >
> > > >
> > > > Regards
> > > > Jiwei Guo (Tboy)
> > > >
> >

Re: [VOTE] Pulsar Release 3.2.0 Candidate 5

[Yunze Xu]

-1 (binding)

I observed a regression for Pulsar 3.1.2 recently because the latest
image was just updated yesterday [1]. It seems related to the SSL
hostname verification because the failed tests come from
https://github.com/apache/pulsar-client-cpp/pull/126. I tested the
`technoboy8/pulsar:3.2.0-8025763` image locally and found the tests
still failed. You can also check the CI test result [2].

Currently, I'm debugging locally to see why the tests failed. Before
figuring it out, we should prevent this release.

[1] https://github.com/apache/pulsar-client-cpp/pull/392#issuecomment-1922698516
[2] https://github.com/apache/pulsar-client-cpp/pull/394

Thanks,
Yunze

On Thu, Feb 1, 2024 at 8:57 AM PengHui Li  wrote:
>
> +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 Wed, Jan 31, 2024 at 11:40 PM guo jiwei  wrote:
>
> > This is the fifth 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 vote will stay
> > open for at least 72 hours ***
> >
> > 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-5/
> >
> > SHA-512 checksums:
> >
> >
> > 194b3a4d51b972ec58c8f2ae4ccaadb3cac229984ea5e7e8a396a1210d4b3adde83ab30ef31c9aa384942f81959da91ab250f5689cd010b4ae71a2b10956af2c
> >
> > apache-pulsar-3.2.0-bin.tar.gz
> >
> >
> > 7248f2566627d772093204a61ae2ea87b58dd18f374d2fd624827eb95f4102bfe07b2be87a4e7b6c7c296c5791af623f308885bfbe89069d10620f9da73ded93
> >
> > apache-pulsar-3.2.0-src.tar.gz
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachepulsar-1265/
> >
> > The tag to verify:
> > v3.2.0-candidate-5 (802576372132617b5076a44004846f2dbabede08)
> > https://github.com/apache/pulsar/commits/v3.2.0-candidate-5/
> >
> > 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-8025763/images/sha256-4666cc754439a2e6844569bb500365ded382b81d8fc9d4552e3c435702b59d86?context=repo
> > <
> > https://hub.docker.com/layers/mattison/pulsar/3.1.0-candidate-1/images/sha256-0efbaad7d893cc5041a46a2d4d56432bda855ae4068a38349777d1be6e98d27d?context=explore
> > >
> > pulsar-all images:
> >
> > https://hub.docker.com/layers/technoboy8/pulsar-all/3.2.0-8025763/images/sha256-b308fd819298bb2badc20ecd86547c43a7c8652aebd716816c7f8f24dbb1b34e?context=repo
> >
> > Please download the source package, and follow the README to build
> > and run the Pulsar standalone service.
> >
> >
> >
> > Regards
> > Jiwei Guo (Tboy)
> >

Re: [VOTE] Pulsar Node.js Client Release 1.10.0 Candidate 1

[Yunze Xu]

+1 (binding)

* Verified checksum and signatures
* Built from source on macOS m1 and run examples
* Install the NPM on macOS m1 and connect to StreamNative cloud via
OAuth2 authentication

Thanks,
Yunze

On Mon, Jan 29, 2024 at 6:11 PM Baodi Shi  wrote:
>
> Hi everyone,
>
> This is the first release candidate for Apache Pulsar Node.js client,
> version 1.10.0.
>
> It fixes the following issues:
> https://github.com/apache/pulsar-client-node/milestone/15?closed=1
>
> Please download the source files and review this release candidate:
> - Download the source package, verify shasum and asc
> - Follow the README.md to build and run the Pulsar Node.js client.
>
> The release candidate package has been published to the npm registry:
> https://www.npmjs.com/package/pulsar-client/v/1.10.0-rc.1
> You can install it by `npm i pulsar-client@1.10.0-rc.1
> --pulsar_binary_host_mirror=
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/` and
> verify the package.
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Source files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/pulsar-client-node-1.10.0-rc.1/
>
> Pulsar's KEYS file containing PGP keys we use to sign the release:
> https://downloads.apache.org/pulsar/KEYS
>
> SHA-512 checksum:
> 3e2c76ff8340597129eec1ab2a9cdbdd48fb162257426c474bd637bb02a45b49011e6b31e08679022f18d700e73f49cbb8adc59f75e345db9220a2b755eccac4
> ./apache-pulsar-client-node-1.10.0.tar.gz
>
> The tag to be voted upon:
> v1.10.0-rc.1
> https://github.com/apache/pulsar-client-node/releases/tag/v1.10.0-rc.1
>
> Please review and vote on the release candidate #1 for the version 1.10.0,
> as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)

Re: [VOTE] Pulsar Client Go Release 0.12.0 Candidate 3

[Yunze Xu]

+1 (binding)

- Verified checksum and signatures
- Built from source
- Verified perf tool against a local 3.1.2 standalone
- Verified produce and consume via OAuth2 authentication against
StreamNative cloud

Thanks,
Yunze

On Wed, Jan 24, 2024 at 8:47 PM PengHui Li  wrote:
>
> +1 (binding)
>
> - Build from source
> - Run tests on 3.1.2
> - Run tests on 3.0.2
>
> Regards,
> Penghui
>
> On Wed, Jan 24, 2024 at 2:59 PM Zike Yang  wrote:
>
> > Hi everyone,
> > Please review and vote on the release candidate #3 for the version
> > 0.12.0, as follows:
> > [ ] +1, Approve the release
> > [ ] -1, Do not approve the release (please provide specific comments)
> >
> > This is the third release candidate for Apache Pulsar Go client,
> > version 0.12.0.
> >
> > The release note/changelog for Go client 0.12.0:
> > https://github.com/apache/pulsar-client-go/pull/1153/files
> >
> > Pulsar Client Go's KEYS file contains PGP keys we used to sign this
> > release:
> > https://downloads.apache.org/pulsar/KEYS
> >
> > Please download these packages and review this release candidate:
> > - Review release notes:
> > https://github.com/apache/pulsar-client-go/pull/1153
> > - Download the source package (verify shasum, and asc) and follow the
> > README.md to build and run the pulsar-client-go.
> >
> > The vote will be open for at least 72 hours. It is adopted by majority
> > approval, with at least 3 PMC affirmative votes.
> >
> > Source file:
> >
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.12.0-candidate-3/
> >
> > The tag to be voted upon:
> > v0.12.0-candidate-3
> > https://github.com/apache/pulsar-client-go/tree/v0.12.0-candidate-3
> >
> > SHA-512 checksums:
> >
> > 66c37c4439549a02d7e3d21ecc02c4a2f44bad2232fbf15fb04c42f02fc4caad758b7a1b1663d0df47414af99daa4e3a19d33c29c0decbc43ac4d17e46a126bc
> >  apache-pulsar-client-go-0.12.0-src.tar.gz
> >

Re: [VOTE] Pulsar Client Go Release 0.12.0 Candidate 2

[Yunze Xu]

I agree with retaining this file in this 0.12.0 release to avoid some
unexpected changes. We can estimate whether it's safe to remove the
VERSION file later.

Thanks,
Yunze

On Mon, Jan 22, 2024 at 10:18 AM Zike Yang  wrote:
>
>  Hi yunze,
>
> Thanks for reporting this. Actually, the `VERSION` file is not used in
> the code even before that PR. We currently have two hardcoded version
> files in place: `VERSION` which represents the current version and
> `stable.txt` which represents the current stable version. However, I'm
> curious about the intended function of these files. Are they merely
> for developers to conveniently reference the current and stable
> versions? And what is our approach to managing these files? For
> instance, how do we determine what constitutes a stable version? If
> there's no compelling reason to keep these files, I'd support their
> removal.
>
> Regarding the current 0.12.0 release, before we make a consensus on
> whether we should remove these files. I can update the current version
> in those files in the next release candidate.
>
> Thanks,
> Zike Yang
>
> On Fri, Jan 19, 2024 at 4:27 PM Yunze Xu  wrote:
> >
> > The VERSION file is still 0.11.1, which is not updated. But it seems
> > that this VERSION file is not used anywhere. I checked the stats and
> > found the "clientVersion" is "Pulsar Go v0.12.0-candidate-2", which is
> > expected.
> >
> > I see https://github.com/apache/pulsar-client-go/pull/856 supports
> > getting the version from the dependency, then the hard-coded VERSION
> > file is no longer needed. I think we can remove that file in the
> > 0.12.0 or next release. But we should not maintain a file that could
> > make users confused (i.e. the source code of 0.12.0 contains a version
> > file of 0.11.1)
> >
> > Thanks,
> > Yunze
> >
> > On Mon, Jan 15, 2024 at 2:41 PM Zike Yang  wrote:
> > >
> > > Hi everyone,
> > > Please review and vote on the release candidate #2 for the version
> > > 0.12.0, as follows:
> > > [ ] +1, Approve the release
> > > [ ] -1, Do not approve the release (please provide specific comments)
> > >
> > > This is the second release candidate for Apache Pulsar Go client,
> > > version 0.12.0.
> > >
> > > The release note/changelog for Go client 0.12.0:
> > > https://github.com/apache/pulsar-client-go/pull/1153/files
> > >
> > > Pulsar Client Go's KEYS file contains PGP keys we used to sign this 
> > > release:
> > > https://downloads.apache.org/pulsar/KEYS
> > >
> > > Please download these packages and review this release candidate:
> > > - Review release notes: 
> > > https://github.com/apache/pulsar-client-go/pull/1153
> > > - Download the source package (verify shasum, and asc) and follow the
> > > README.md to build and run the pulsar-client-go.
> > >
> > > The vote will be open for at least 72 hours. It is adopted by majority
> > > approval, with at least 3 PMC affirmative votes.
> > >
> > > Source file:
> > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.12.0-candidate-2/
> > >
> > > The tag to be voted upon:
> > > v0.12.0-candidate-2
> > > https://github.com/apache/pulsar-client-go/tree/v0.12.0-candidate-2
> > >
> > > SHA-512 checksums:
> > > e3c0845f60989b9ca4f6cf683d750c9361ca0e15ae7f8d990cfe14d7af86bd80475aeeda95870f2b8ef6fe8ec5fdbd59c67876546e282d76baae9a1737c6a7aa
> > >  apache-pulsar-client-go-0.12.0-src.tar.gz

Re: [VOTE] Pulsar Client Go Release 0.12.0 Candidate 2

[Yunze Xu]

The VERSION file is still 0.11.1, which is not updated. But it seems
that this VERSION file is not used anywhere. I checked the stats and
found the "clientVersion" is "Pulsar Go v0.12.0-candidate-2", which is
expected.

I see https://github.com/apache/pulsar-client-go/pull/856 supports
getting the version from the dependency, then the hard-coded VERSION
file is no longer needed. I think we can remove that file in the
0.12.0 or next release. But we should not maintain a file that could
make users confused (i.e. the source code of 0.12.0 contains a version
file of 0.11.1)

Thanks,
Yunze

On Mon, Jan 15, 2024 at 2:41 PM Zike Yang  wrote:
>
> Hi everyone,
> Please review and vote on the release candidate #2 for the version
> 0.12.0, as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
> This is the second release candidate for Apache Pulsar Go client,
> version 0.12.0.
>
> The release note/changelog for Go client 0.12.0:
> https://github.com/apache/pulsar-client-go/pull/1153/files
>
> Pulsar Client Go's KEYS file contains PGP keys we used to sign this release:
> https://downloads.apache.org/pulsar/KEYS
>
> Please download these packages and review this release candidate:
> - Review release notes: https://github.com/apache/pulsar-client-go/pull/1153
> - Download the source package (verify shasum, and asc) and follow the
> README.md to build and run the pulsar-client-go.
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Source file:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.12.0-candidate-2/
>
> The tag to be voted upon:
> v0.12.0-candidate-2
> https://github.com/apache/pulsar-client-go/tree/v0.12.0-candidate-2
>
> SHA-512 checksums:
> e3c0845f60989b9ca4f6cf683d750c9361ca0e15ae7f8d990cfe14d7af86bd80475aeeda95870f2b8ef6fe8ec5fdbd59c67876546e282d76baae9a1737c6a7aa
>  apache-pulsar-client-go-0.12.0-src.tar.gz

Re: [VOTE] PIP-329: Strategy for maintaining the latest tag to Pulsar docker images

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Wed, Jan 17, 2024 at 12:37 PM PengHui Li  wrote:
>
> +1 (binding)
>
> Regards,
> Penghui
>
> On Wed, Jan 17, 2024 at 11:05 AM guo jiwei  wrote:
>
> > +1 (binding)
> >
> >
> > Regards
> > Jiwei Guo (Tboy)
> >
> >
> > On Mon, Jan 15, 2024 at 5:50 PM Zixuan Liu  wrote:
> >
> > > +1(non-binding)
> > >
> > > Thanks,
> > > Zixuan
> > >
> > > Zike Yang  于2024年1月15日周一 16:14写道：
> > >
> > > > Hi, all
> > > >
> > > > I'm starting the vote for PIP-329: Strategy for maintaining the latest
> > > > tag to Pulsar docker images
> > > >
> > > > PIP link: https://github.com/apache/pulsar/pull/21872
> > > >
> > > > Thanks,
> > > > Zike Yang
> > > >
> > >
> >

Re: [DISCUSS] Always set a broker side timestamp for message and deprecate some API

[Yunze Xu]

I see, it only affects the TTL. We can acknowledge the messages to
clean up the data. Then we have to document the `brokerInterceptors`
config clearly to say TTL might not work if
`AppendBrokerTimestampMetadataInterceptor` is not configured.

Thanks,
Yunze

On Thu, Jan 18, 2024 at 10:41 AM PengHui Li  wrote:
>
> > I don't think we should provide such an option for users. Compared
> with the serious security issue, the extra overhead (13 bytes) per
> entry (not per message) should never be a concern.
>
> It actually changed the stored data format. As far as I know, there are
> some users
> who read data from the offloaded data files directly. So, at least, we
> should provide
> a way to allow them to avoid the stored data format change.
>
> And 13 bytes are also related to the use case. If users don't use TTL and
> send
> too many small messages without batch. The cost will be increased by 10% or
> 20%.
> The issue will not damage the data or cause the data loss.
> You can monitor it, to skip the backlogs. TTL is not the only way to evict
> backlogs.
>
> Thanks,
> Penghui
>
> On Thu, Jan 18, 2024 at 10:33 AM PengHui Li  wrote:
>
> > > We should also improve the TTL:
> > > When client publish time > Ledger create time + Ledger rollover time,
> > > and `brokerPublishTime` is not set,
> > > we can make Ledger TTL time =  Ledger create time + Ledger rollover
> > time.
> >
> > > This change can make sure entry expires when client clock is not right.
> >
> > This solution looks good to me.
> >
> > Regards,
> > Penghui
> >
> >
> > On Wed, Jan 17, 2024 at 10:31 PM Yunze Xu  wrote:
> >
> >> From my perspective, it's a serious security issue. The client side
> >> could easily make Pulsar's message expiry mechanism not work. Even if
> >> it's not a malicious change made by users, it would be hard to figure
> >> out what makes the message not expired.
> >>
> >> > Users can still have a way to disable it if they care about the
> >> additional metadata stored in each entry.
> >>
> >> I don't think we should provide such an option for users. Compared
> >> with the serious security issue, the extra overhead (13 bytes) per
> >> entry (not per message) should never be a concern.
> >>
> >> My suggestion is that the broker entry metadata with the broker side
> >> timestamp should always be generated and we should not allow users to
> >> disable it. However, `hasBrokerPublishTime` should not be deprecated.
> >> The broker entry metadata won't be transferred to the client unless
> >> `exposingBrokerEntryMetadataToClientEnabled` is true.
> >>
> >> Thanks,
> >> Yunze
> >>
> >> On Wed, Jan 17, 2024 at 6:45 PM Lin Lin  wrote:
> >> >
> >> > Only enabled `AppendBrokerTimestampMetadataInterceptor` is not enough.
> >> >
> >> > We should also improve the TTL:
> >> > When client publish time > Ledger create time + Ledger rollover time,
> >> > and `brokerPublishTime` is not set,
> >> > we can make Ledger TTL time =  Ledger create time + Ledger rollover
> >> time.
> >> >
> >> > This change can make sure entry expired when client clock is not right.
> >> >
> >> > On 2024/01/17 04:31:16 PengHui Li wrote:
> >> > > > User disabling `AppendBrokerTimestampMetadataInterceptor` does not
> >> mean
> >> > > that they allow this bug.
> >> > > This is a configuration, not an API. It is difficult to use
> >> documentation
> >> > > to regulate user behavior.
> >> > >
> >> > > Actually, they need to know why they want to disable `
> >> > > AppendBrokerTimestampMetadataInterceptor`.
> >> > > Otherwise, why do they want to disable `AppendBrokerTimestampMetadata
> >> > > Interceptor`?
> >> > >
> >> > > Pulsar's default configuration tries to provide a best practice for
> >> most of
> >> > > the cases. To avoid the potential
> >> > > problem, Pulsar enables  `AppendBrokerTimestampMetadataInterceptor` by
> >> > > default. But it doesn't mean all the cases
> >> > > should enable `AppendBrokerTimestampMetadataInterceptor`. If users
> >> don't
> >> > > use TTL, the producers are
> >> > > well-maintained. Is there any reason to have at least 16 bytes append
> >> to
> >> > > each entry? The default configuration
>

Re: [DISCUSS] Always set a broker side timestamp for message and deprecate some API

[Yunze Xu]

>From my perspective, it's a serious security issue. The client side
could easily make Pulsar's message expiry mechanism not work. Even if
it's not a malicious change made by users, it would be hard to figure
out what makes the message not expired.

> Users can still have a way to disable it if they care about the additional 
> metadata stored in each entry.

I don't think we should provide such an option for users. Compared
with the serious security issue, the extra overhead (13 bytes) per
entry (not per message) should never be a concern.

My suggestion is that the broker entry metadata with the broker side
timestamp should always be generated and we should not allow users to
disable it. However, `hasBrokerPublishTime` should not be deprecated.
The broker entry metadata won't be transferred to the client unless
`exposingBrokerEntryMetadataToClientEnabled` is true.

Thanks,
Yunze

On Wed, Jan 17, 2024 at 6:45 PM Lin Lin  wrote:
>
> Only enabled `AppendBrokerTimestampMetadataInterceptor` is not enough.
>
> We should also improve the TTL:
> When client publish time > Ledger create time + Ledger rollover time,
> and `brokerPublishTime` is not set,
> we can make Ledger TTL time =  Ledger create time + Ledger rollover time.
>
> This change can make sure entry expired when client clock is not right.
>
> On 2024/01/17 04:31:16 PengHui Li wrote:
> > > User disabling `AppendBrokerTimestampMetadataInterceptor` does not mean
> > that they allow this bug.
> > This is a configuration, not an API. It is difficult to use documentation
> > to regulate user behavior.
> >
> > Actually, they need to know why they want to disable `
> > AppendBrokerTimestampMetadataInterceptor`.
> > Otherwise, why do they want to disable `AppendBrokerTimestampMetadata
> > Interceptor`?
> >
> > Pulsar's default configuration tries to provide a best practice for most of
> > the cases. To avoid the potential
> > problem, Pulsar enables  `AppendBrokerTimestampMetadataInterceptor` by
> > default. But it doesn't mean all the cases
> > should enable `AppendBrokerTimestampMetadataInterceptor`. If users don't
> > use TTL, the producers are
> > well-maintained. Is there any reason to have at least 16 bytes append to
> > each entry? The default configuration
> > behavior change also needs to be highlighted in the release note. Users
> > need to know if they don't disable the
> > `AppendBrokerTimestampMetadataInterceptor` manually on a newer version, the
> > retained data size will increase.
> >
> > BTW, we need to explain each interceptor in the `broker.conf` and why `
> > AppendBrokerTimestampMetadataInterceptor`
> > is enabled by default. If users don't want to read it, change anything in
> > `broker.conf` they don't really know what it is.
> > How can they know what they expect?
> >
> > Regards,
> > Penghui
> >
> >
> > On Mon, Jan 15, 2024 at 11:09 PM Lin Lin  wrote:
> >
> > > User disabling `AppendBrokerTimestampMetadataInterceptor` does not mean
> > > that they allow this bug.
> > > This is a configuration, not an API. It is difficult to use documentation
> > > to regulate user behavior.
> > >
> > > Maybe we can add a new field (BrokerTimestamp) to save the timestamp on
> > > the Broker side.
> > > The time priority for trimming Ledger is as follows:
> > >
> > > BrokerPublishTime > BrokerTimestamp
> > >
> > > If `BrokerPublishTime` exists, `BrokerReceiveTime` is not set.
> > > If not, we set `BrokerReceiveTime`  and is no longer affected by client
> > > time.
> > >
> > > On 2024/01/15 02:15:17 PengHui Li wrote:
> > > > IMO, we should enable `AppendBrokerTimestampMetadataInterceptor` by
> > > default.
> > > > Users can still have a way to disable it if they care about the
> > > additional
> > > > metadata stored
> > > > in each entry.
> > > >
> > > > For the `hasBrokerPublishTime` API. The topic might also have historical
> > > > data without
> > > > broker publish time. So, it should be fine to keep this API because we
> > > > don't know how
> > > > long users will retain their data.
> > > >
> > > > Regards,
> > > > Penghui
> > > >
> > > > On Sat, Jan 6, 2024 at 10:35 PM linlin  wrote:
> > > >
> > > > > Now, if the message's metadata does not set a broker side timestamp,
> > > the
> > > > > ledger expiration check is based on the client's publish time.
> > > > >
> > > > > When the client machine's clock is incorrect (eg: set to 1 year later)
> > > ,
> > > > > the ledger can not be cleaned up. Issue
> > > > > https://github.com/apache/pulsar/issues/21347
> > > > >
> > > > > `AppendBrokerTimestampMetadataInterceptor` can set timestamp for
> > > messages
> > > > > on the broker side, but we can not ensure that the
> > > > > `AppendBrokerTimestampMetadataInterceptor` is always enable
> > > > >
> > > > > Therefore, I open this PR(https://github.com/apache/pulsar/pull/21835)
> > > to
> > > > > always set the broker timestamp for messages on the broker side.
> > > > >
> > > > > With this change , firstly we should deprecate
> > > > > 

Re: [VOTE] PIP-330: getMessagesById gets all messages

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Wed, Jan 17, 2024 at 6:55 PM guo jiwei  wrote:
>
> +1 (binding)
>
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Wed, Jan 17, 2024 at 5:39 PM 太上玄元道君  wrote:
>
> > +1 nonbinding
> >
> >
> > > 2024年1月17日 17:35，Asaf Mesika  写道：
> > >
> > > +1 (non-binding)
> > >
> > > On Tue, Jan 16, 2024 at 4:43 AM Dezhi Liu  wrote:
> > >
> > >> +1 (non-binding)
> > >>
> > >> Thanks,
> > >> Dezhi Liu
> > >>
> > >> On 2024/01/15 09:33:48 Zixuan Liu wrote:
> > >>> Hi Pulsar Community,
> > >>>
> > >>> Voting for PIP-330: getMessagesById gets all messages
> > >>>
> > >>> PIP: https://github.com/apache/pulsar/pull/21873
> > >>> Discussion thread:
> > >>> https://lists.apache.org/thread/vqyh3mvtvovd383sd8zxnlzsspdr863z
> > >>>
> > >>> Thanks,
> > >>> Zixuan
> > >>>
> > >>
> >
> >

Re: [VOTE] PIP-325: Add command to abort transaction

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Mon, Jan 15, 2024 at 10:25 AM guo jiwei  wrote:
>
> +1 (binding)
>
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Mon, Jan 15, 2024 at 9:36 AM PengHui Li  wrote:
>
> > +1 (binding)
> >
> > Regards,
> > Penghui
> >
> > On Mon, Jan 8, 2024 at 4:00 PM Enrico Olivelli 
> > wrote:
> >
> > > +1 (binding)
> > >
> > >
> > > Enrico
> > >
> > > Il Lun 8 Gen 2024, 03:55 ruihongzhou  ha
> > > scritto:
> > >
> > > > Hi community,
> > > >
> > > > This thread is to start a vote for PIP-325: Add command to abort
> > > > transaction.
> > > >
> > > > PIP: https://github.com/apache/pulsar/pull/21731
> > > >
> > > > Releted PR: https://github.com/apache/pulsar/pull/21630
> > > >
> > > >  Discussion thread:
> > > > https://lists.apache.org/thread/ssgngyrlgx36zvygvsd5b2dm5q6krn0f
> > > >
> > > > Ruihong
> > > >
> > > >
> > > >
> > > > ruihongzhou
> > > > ruihongz...@qq.com
> > > >
> > > >
> > > >
> > > > 
> > >
> >

Re: [VOTE] Pulsar Client Go Release 0.12.0 Candidate 1

[Yunze Xu]

Could you include this fix
(https://github.com/apache/pulsar-client-go/pull/1155), which fixes a
CVE?

Thanks,
Yunze

On Wed, Jan 10, 2024 at 3:21 PM Zike Yang  wrote:
>
> Hi everyone,
> Please review and vote on the release candidate #1 for the version
> 0.12.0, as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
> This is the first release candidate for Apache Pulsar Go client, version 
> 0.12.0.
>
> The release note/changelog for Go client 0.12.0:
> https://github.com/apache/pulsar-client-go/pull/1153/files
>
> Pulsar Client Go's KEYS file contains PGP keys we used to sign this release:
> https://downloads.apache.org/pulsar/KEYS
>
> Please download these packages and review this release candidate:
> - Review release notes: https://github.com/apache/pulsar-client-go/pull/1153
> - Download the source package (verify shasum, and asc) and follow the
> README.md to build and run the pulsar-client-go.
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Source file:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.12.0-candidate-1/
>
> The tag to be voted upon:
> v0.12.0-candidate-1
> https://github.com/apache/pulsar-client-go/tree/v0.12.0-candidate-1
>
> SHA-512 checksums:
> a32e1072646a13aa54f983f0d3fce9c1917773fcb261d3431e2ecf1bac519cf50d3e8c3479f527e3ec8fb69518e987f25f1e3b9eae6736739aaea77941766304
>  apache-pulsar-client-go-0.12.0-src.tar.gz

[DISCUSS] Add a new set of Python Client APIs for asyncio and coroutines

[Yunze Xu]

Hi all,

Recently I noticed the Pulsar Python client APIs are not friendly to
Python users [1]. The existing asynchronous APIs are based on
callbacks and they are hard to use. Since the Pulsar Python client is
a wrapper on the Pulsar C++ client, wrapping the existing
callback-based APIs for asyncio requires much knowledge on the
underlying C++ implementation details [2].

For the reasons above, I think it will be helpful to provide another
set of APIs based on asyncio and coroutines. I opened my first PR [3]
as the beginning. Instead of rewriting a new project, I'd like to add
a submodule `pulsar.asyncio` for these APIs that share the same C
extension with APIs in the `pulsar` module.

The new APIs are in development and do not affect the original APIs,
which are actually not tested well, see the regression [4]. Instead of
adding more tests to existing APIs, I'd like to pay more attention
when adding new APIs. Tests are required for each new configuration.

Feel free to share your thoughts on this!

[1] https://github.com/apache/pulsar-client-python/issues/184
[2] 
https://github.com/apache/pulsar-client-python/issues/55#issuecomment-1759925342
[3] https://github.com/apache/pulsar-client-python/pull/189
[4] https://github.com/apache/pulsar-client-python/issues/178

Thanks,
Yunze

Re: [VOTE] Pulsar Client Python Release 3.4.0 Candidate 1

[Yunze Xu]

+1 (binding)

For source code,
* verified signatures and checksums
* built from source on macOS (with C++ client 3.4.2)

For the following wheels, verified end-to-end with OAuth2
authentication on specific platforms.
* the wheel built from source (macOS Ventura 13.6.3)
* pulsar_client-3.4.0-cp312-cp312-macosx_10_15_universal2.whl (macOS
Ventura 13.6.3)
* pulsar_client-3.4.0-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
(Rocky Linux 9)
* 
pulsar_client-3.4.0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
(Ubuntu 22.04)

Thanks,
Yunze

On Thu, Dec 28, 2023 at 5:13 PM PengHui Li  wrote:
>
> +1 (binding)
>
> - Checked the signature
> - Install the pulsar_client-3.4.0-cp39-cp39-macosx_10_15_universal2.whl
> - Run Pulsar standalone
> - Run the Python examples `python3 ./examples/consumer.py` and `python3
> ./examples/producer.py`
>
> Regards,
> Penghui
>
> On Tue, Dec 26, 2023 at 4:54 PM Zike Yang  wrote:
>
> > This is the first release candidate for Apache Pulsar Client Python,
> > version 3.4.0.
> >
> > It fixes the following issues:
> > https://github.com/apache/pulsar-client-python/milestone/5?closed=1
> >
> > *** Please download, test and vote on this release. This vote will
> > stay open for at least 72 hours ***
> >
> > Python wheels:
> >
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.4.0-candidate-1/
> >
> > The supported python versions are 3.8, 3.9, 3.10, 3.11 and 3.12. The
> > supported platforms and architectures are:
> > - Windows x86_64 (windows/)
> > - glibc-based Linux x86_64 (linux-glibc-x86_64/)
> > - glibc-based Linux arm64 (linux-glibc-arm64/)
> > - musl-based Linux x86_64 (linux-musl-x86_64/)
> > - musl-based Linux arm64 (linux-musl-arm64/)
> > - macOS universal 2 (macos/)
> >
> > You can download the wheel (the `.whl` file) according to your own OS
> > and Python version
> > and install the wheel:
> > - Windows: `py -m pip install *.whl --force-reinstall`
> > - Linux or macOS: `python3 -m pip install *.whl --force-reinstall`
> >
> > The tag to be voted upon: v3.4.0-candidate-1
> > (v3.4.0-candidate-1)
> > https://github.com/apache/pulsar-client-python/tree/v3.4.0-candidate-1
> >
> > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > https://downloads.apache.org/pulsar/KEYS
> >
> > Please download the Python wheels and follow the README to test.
> >

Re: [DISCUSS] Return value of org.apache.pulsar.client.admin.Topics#getMessageById

[Yunze Xu]

IMO, exposing the ledger id and entry id directly through the API is
not a good idea. For example, what if you want to get a chunked
message? You would have to add another field again and deprecate the
existing method.

I think we should just accept a string like
"bk:ledger:entry:batch_index" that represents a MessageID instead. If
we're going to replace BK with other storage systems in future (though
I think it's far way from now), we can still reuse this API.

Thanks,
Yunze

On Thu, Dec 28, 2023 at 5:21 PM Zixuan Liu  wrote:
>
> Hi Pulsar Community,
>
> I want to discuss the return value of the
> `org.apache.pulsar.client.admin.Topics#getMessageById`, which returns
> `Message`. If the message is a batch message, we only get the first
> message from the batch message.
>
> So I want to change this behavior by returning `List`, and
> in the CLI, we also need to print multiple messages when using
> `get-message-by-id`.
>
> Now, I am adding a new method with the same name and a `batchIndex`
> parameter. When "batchIndex" is -1, we can retrieve all messages from the
> batch message. Otherwise, we get one message by giving the index. For this
> implementation, please see  https://github.com/apache/pulsar/pull/21813.
>
> In long time ago, there was also a PR to fix this issue, please see
> https://github.com/apache/pulsar/pull/19827.
>
> Two PR uses different ways to fix this issue, please let me know your
> thoughts!
>
> Thanks,
> Zixuan

[ANNOUNCE] Apache Pulsar Client C++ 3.4.2 released

[Yunze Xu]

The Apache Pulsar team is proud to announce Apache Pulsar Client C++
version 3.4.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/#pulsar-c-client

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

API documents are at:
https://pulsar.apache.org/api/cpp/3.4.x/index.html

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

Regards,

The Pulsar Team

Re: [VOTE] Pulsar Client C++ Release 3.4.2 Candidate 1

[Yunze Xu]

Close this vote by 3 binding +1s
- Tison
- Jiwei
- Penghui

Thanks,
Yunze

On Thu, Dec 14, 2023 at 7:51 PM PengHui Li  wrote:
>
> +1 (binding)
>
> - Checked the signature
> - Tested the producer and consumer
>
> Regards,
> Penghui
>
> On Wed, Dec 13, 2023 at 2:28 PM guo jiwei  wrote:
>
> > +1 (binding)
> >
> > - Verified the signature and checksum
> > - Build from the source
> > - Test SampleConsumer and SampleProducer
> >
> > Regards
> > Jiwei Guo (Tboy)
> >
> >
> > On Tue, Dec 12, 2023 at 4:30 PM tison  wrote:
> >
> > > +1 (binding)
> > >
> > > * Download URL valid
> > > * Checksum and sign match
> > > * Can build from source
> > > * LICENSE and NOTICE present
> > >
> > > nit: Years in NOTICE can be updated.
> > >
> > > Best,
> > > tison.
> > >
> > > Yunze Xu  于2023年12月6日周三 16:00写道：
> > > >
> > > > This is the first release candidate for Apache Pulsar Client C++,
> > > version 3.4.2.
> > > >
> > > > It fixes the following issues:
> > > >
> > >
> > https://github.com/apache/pulsar-client-cpp/pulls?q=is%3Apr+is%3Aclosed+label%3Arelease%2F3.4.2
> > > >
> > > > *** 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-client-cpp/pulsar-client-cpp-3.4.2-candidate-1/
> > > >
> > > > SHA-512 checksums:
> > > >
> > >
> > d64a07c4f78071ae0607f1afac4ab0db15f9dc25cb1f2ceae7152e262b65e660719f1520f93933da6615691ea0de2f25a6fb2806369126c4a777c0a075af0f5e
> > > >  apache-pulsar-client-cpp-3.4.2.tar.gz
> > > >
> > > > The tag to be voted upon:
> > > > v3.4.2-candidate-1 (1cb1bf8ba1ca1033b4a36d35514f22fcf150973a)
> > > >
> > >
> > https://github.com/apache/pulsar-client-cpp/releases/tag/v3.4.2-candidate-1
> > > >
> > > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > > https://downloads.apache.org/pulsar/KEYS
> > > >
> > > > Please download the source package, and follow
> > > >
> > >
> > https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
> > > > to compile and test.
> > > >
> > > > Note: If you're going to run the unit tests locally, please make sure
> > > > the proxy is disabled.
> > >
> >

Re: [DISCUSS] PIP-324: Alpine Docker images

[Yunze Xu]

+1 to me. The Alpine Linux is much more light-weight than Ubuntu.

Thanks,
Yunze

On Wed, Dec 13, 2023 at 3:00 AM Matteo Merli  wrote:
>
> Hello,
>
> I've created a new proposal to switch Pulsar base docker images from Ubuntu
> to Alpine Linux.
>
> Details and motivation in the PIP:
> https://github.com/apache/pulsar/pull/21716
>
> Matteo
>
> --
> Matteo Merli
> 

Re: [VOTE] PIP-313 Support force unsubscribe using consumer api

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Mon, Dec 11, 2023 at 2:18 PM Apurva Telang  wrote:
>
> +1 (non-binding)
>
> On Sun, Dec 10, 2023 at 6:12 PM guo jiwei  wrote:
>
> > +1 (binding)
> >
> >
> > Regards
> > Jiwei Guo (Tboy)
> >
> >
> > On Thu, Dec 7, 2023 at 4:38 PM Rajan Dhabalia 
> > wrote:
> >
> > > Hi,
> > >
> > > I would like to start voting thread for PIP-313  which also addresses
> > issue
> > > # https://github.com/apache/pulsar/issues/21451
> > >
> > > PIP design PR:
> > > https://github.com/apache/pulsar/pull/21452
> > >
> > > Thread:
> > > https://lists.apache.org/thread/hptx8z9mktn94gvqtt4547wzcfcgdsrv
> > >
> > > Thanks,
> > > Rajan
> > >
> >
>
>
> --
> Best regards,
> Apurva Telang.

Re: [VOTE] PIP-320: OpenTelemetry Scaffolding

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Mon, Dec 11, 2023 at 3:34 PM Asaf Mesika  wrote:
>
> Hi,
>
> I'm starting the vote for PIP-320 (1st sub-PIP of PIP-264)
>
> Link: https://github.com/apache/pulsar/pull/21635
>
> Reminder:
> This PIPs goal is to introduce OpenTelemetry into Apache Pulsar. When this
> PIP is implemented, we will be able to start converting (not replacing)
> existing metrics into OpenTelemetry.
>
>
> Thank you!
>
> Asaf Mesika

Re: [VOTE] DotPulsar Release 3.1.1 RC 1

[Yunze Xu]

+1 (binding)

* Verified checksum and signatures
* Build from source with dotnet 8.0.100 on macOS m1
* Verified producing and consuming for the Nuget package

Thanks,
Yunze


On Fri, Dec 8, 2023 at 3:32 PM tison  wrote:
>
> +1 (binding)
>
> + Signature and checksum match
> + Download link valid
> + Can compile from source (on macOS aarch64)
> + LICENSE and NOTICE present
>
> Best,
> tison.
>
> Daniel Blankensteiner  于2023年12月8日周五 15:24写道：
> >
> > +1 (binding)
> >
> > Tested on Windows 10 with .NET 8(.0.100).
> >
> > Best regards
> >
> > Daniel Blankensteiner
> >
> > tison skrev den 2023-12-07 03:14:
> > > Hi everyone,
> > >
> > > This is a quick fix patch release for exactly
> > > https://github.com/apache/pulsar-dotpulsar/commit/f35e6824f0790696bf4300dcd7a00967cf6c250e
> > > :
> > >
> > > Fixed a bug where disposing a disconnected consumer, reader or
> > > producer would cause a hang
> > >
> > > Please review and vote on the release candidate #1 for the version
> > > 3.1.1, as follows:
> > > [ ] +1, Approve the release
> > > [ ] -1, Do not approve the release (please provide specific comments)
> > >
> > > DotPulsar's KEYS file contains PGP keys we used to sign this release:
> > > https://downloads.apache.org/pulsar/KEYS
> > >
> > > Please download these packages and review this release candidate:
> > > - Review release notes
> > > - Download the source package (verify shasum, and asc) and follow the
> > > README.md to build and run DotPulsar.
> > >
> > > The vote will be open for at least 72 hours. It is adopted by majority
> > > approval, with at least 3 PMC affirmative votes.
> > >
> > > Source file:
> > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-dotpulsar-3.1.1-rc.1/
> > >
> > > Nuget package:
> > > https://www.nuget.org/packages/DotPulsar/3.1.1-rc.1
> > >
> > > The tag to be voted upon:
> > > https://github.com/apache/pulsar-dotpulsar/tree/3.1.1-rc.1
> > >
> > > SHA-512 checksums:
> > > 784a0afb1a78122bb4c90ed8b2a3945b14628c78b9c0b902e376c74fa0b0d644ace8646357a22fbbebaac5929e0f7781deb416f17c68bb354903159023b5e012
> > >  pulsar-dotpulsar-3.1.1.tar.gz
> > >
> > > Best,
> > > tison.

[VOTE] Pulsar Client C++ Release 3.4.2 Candidate 1

[Yunze Xu]

This is the first release candidate for Apache Pulsar Client C++, version 3.4.2.

It fixes the following issues:
https://github.com/apache/pulsar-client-cpp/pulls?q=is%3Apr+is%3Aclosed+label%3Arelease%2F3.4.2

*** 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-client-cpp/pulsar-client-cpp-3.4.2-candidate-1/

SHA-512 checksums:
d64a07c4f78071ae0607f1afac4ab0db15f9dc25cb1f2ceae7152e262b65e660719f1520f93933da6615691ea0de2f25a6fb2806369126c4a777c0a075af0f5e
 apache-pulsar-client-cpp-3.4.2.tar.gz

The tag to be voted upon:
v3.4.2-candidate-1 (1cb1bf8ba1ca1033b4a36d35514f22fcf150973a)
https://github.com/apache/pulsar-client-cpp/releases/tag/v3.4.2-candidate-1

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

Please download the source package, and follow
https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
to compile and test.

Note: If you're going to run the unit tests locally, please make sure
the proxy is disabled.

Re: [DISCUSS] Release Pulsar Python clieng 3.4.0

[Yunze Xu]

Hi Zike,

I found a regression [1] that would affect the Python or Node.js
client if any of them depends on the C++ Client 3.4.1. So I will
prepare a 3.4.2 release soon. Please wait until the C++ client 3.4.2
is released.

[1] https://lists.apache.org/thread/rjolgrlp4x1lmfj678k3hjco80kcb73c

Thanks,
Yunze

On Tue, Dec 5, 2023 at 1:38 PM Jia Zhai  wrote:
>
> +1
>
> On Mon, Dec 4, 2023 at 6:14 PM Enrico Olivelli  wrote:
>
> > +1
> >
> > Enrico
> >
> > Il giorno lun 4 dic 2023 alle ore 08:31 Zike Yang  ha
> > scritto:
> > >
> > > Hi all,
> > >
> > > I would like to propose releasing the Pulsar Python client 3.4.0.
> > >
> > > It's over three months since the release of 3.3.0, and there are 46 new
> > commits:
> > > https://github.com/apache/pulsar-client-python/compare/v3.0.0...main
> > >
> > > The Pulsar C++ client 3.4.1 has been released. I have upgraded the C++
> > > client for the Python client to 3.4.1:
> > > https://github.com/apache/pulsar-client-python/pull/167
> > >
> > > We need to cut a new release. Please let me know if you have any
> > > important fixes that need to be included in Pulsar Python client 3.4.0.
> > >
> > > Thanks,
> > > Zike Yang
> >

[Discuss] Release C++ Client 3.4.2

[Yunze Xu]

Hi all,

There is a regression related to OAuth2 authentication for C++ Client
3.4.0 and 3.4.1:
https://github.com/apache/pulsar-client-cpp/issues/363

Generally, for C++ client users, you won't be affected if you
- don't use OAuth2 authentication
- or build the library from source in your platform
- or use the RPM/DEB/APK pre-built libraries

If you're using pre-built libraries for macOS or you built the Linux
libraries in a specific platform (e.g. RedHat) but provided the
libraries in various Linux platforms (e.g. Ubuntu), there would be no
way to use OAuth2 authentication.

Python and Node.js clients would also be affected because they rely on
the customized `tlsTrustCertsFilePath` config that specifies the CA
cert path for OAuth2 authentication.

Therefore, I pushed a fix
(https://github.com/apache/pulsar-client-cpp/pull/364) and will start
the 3.4.2 release.

Thanks,
Yunze

Re: [DISCUSS] Strategy for pushing the latest tag to Pulsar docker images

[Yunze Xu]

I prefer the 1st way as well.

Thanks,
Yunze

On Tue, Dec 5, 2023 at 5:11 PM Zike Yang  wrote:
>
> Hi, everyone,
>
> There seems to be a gap in our current release process concerning the
> pushing of the latest tag to our Docker images. Specifically, we need
> to decide which version of Pulsar the latest tag should point to.
>
> I have come up with two options:
> 1. The latest tag could point to the most recent feature release or
> the subsequent patch of that feature release. For instance, it could
> currently point to 3.1.1, and in the future, it could point to 3.1.2
> or 3.2.0.
> 2. The latest tag could point to the most recent LTS release or the
> subsequent patch of that LTS release. As an example, it could
> currently point to 3.0.2, and in the future, it could point to 3.0.3
> or 4.0.0.
>
> What do you think? I would prefer the option 1. I have pushed a PR to
> update the release docker image process:
> https://github.com/apache/pulsar-site/pull/745.
> PTAL and leave your comments and feedback here.
>
> Thanks,
> Zike Yang

Re: [ANNOUNCE] Apache Pulsar Client C++ 3.2.0 released

[Yunze Xu]

I focused on other projects in the last few months so I might not have
the plan recently. If someone else is interested in implementing the
transaction feature for the C++ client, welcome your contributions.

Thanks,
Yunze

On Thu, Nov 30, 2023 at 7:55 PM Karthikeyan A
 wrote:
>
> Hi Team,
>
> Any updates on including transaction support on C++ client ?
>
> Thanks & Regards
> Karthikeyan A
>
> -Original Message-
> From: Yunze Xu 
> Sent: 17 May 2023 08:33
> To: dev@pulsar.apache.org
> Subject: Re: [ANNOUNCE] Apache Pulsar Client C++ 3.2.0 released
>
> I have a plan to support the transaction on C++ client next month (June). It 
> might be included in the 3.3.0 release.
>
> Thanks,
> Yunze
>
> On Tue, May 16, 2023 at 10:09 PM Karthikeyan A 
>  wrote:
> >
> > Hi,
> >
> > We have a requirement where the message has been consumed from one topic, 
> > processed it and written to another topic in single transaction.
> > Looks like transaction support related client APIs in C++ is still not 
> > available and that is in roadmap of pulsar delivery.
> >
> > Please let us know the details on when the C++ client library for 
> > Transaction Support will be available for use.
> >
> > Thanks & Regards
> > Karthikeyan A
> >
> >
> > -Original Message-
> > From: Yunze Xu 
> > Sent: 16 May 2023 18:17
> > To: dev@pulsar.apache.org; us...@pulsar.apache.org;
> > annou...@apache.org
> > Subject: [ANNOUNCE] Apache Pulsar Client C++ 3.2.0 released
> >
> > The Apache Pulsar team is proud to announce Apache Pulsar Client C++ 
> > version 3.2.0.
> >
> > 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/client-cpp/
> >
> > We would like to thank the contributors that made the release possible.
> >
> > Regards,
> >
> > The Pulsar Team

Re: Pulsar 3.0.2 docker image only supports arm64 platform

[Yunze Xu]

I found Matteo has updated 3.1.1 as the latest image:
https://hub.docker.com/layers/apachepulsar/pulsar/latest/images/sha256-21e8bf1571e4ab559a51b3f6e524d725cffabe3c6836101f9d7ea7eb1e2bf62c?context=explore

But the 3.0.2 still lacks the image for the amd64 platform.

Thanks,
Yunze

On Mon, Dec 4, 2023 at 12:51 AM Yunze Xu  wrote:
>
> Hi all,
>
> When I ran unit tests for the pulsar-client-cpp repo, which uses
> `apachepulsar/pulsar:latest` image to start a standalone, I found the
> tests failed and the following error [1]:
>
> ```
> standalone The requested image's platform (linux/arm64) does not match
> the detected host platform (linux/amd64/v3) and no specific platform
> was requested
> ```
>
> It seems the 3.0.2 image [2] was only built for the arm64 platform. I
> think there is something wrong with the steps to build the image. It
> breaks the CI for pulsar-client-cpp repo, as well as any other repo
> that depends on the latest image. We should fix the image and push it
> again.
>
> [1] 
> https://github.com/apache/pulsar-client-cpp/actions/runs/7078043224/job/19263093582?pr=360
> [2] 
> https://hub.docker.com/layers/apachepulsar/pulsar/3.0.2/images/sha256-5af72da140f3901bccc0a5b56de8764cd60f0d351011fd1b90c484a30889fbf8?context=explore
>
> Thanks,
> Yunze

Pulsar 3.0.2 docker image only supports arm64 platform

[Yunze Xu]

Hi all,

When I ran unit tests for the pulsar-client-cpp repo, which uses
`apachepulsar/pulsar:latest` image to start a standalone, I found the
tests failed and the following error [1]:

```
standalone The requested image's platform (linux/arm64) does not match
the detected host platform (linux/amd64/v3) and no specific platform
was requested
```

It seems the 3.0.2 image [2] was only built for the arm64 platform. I
think there is something wrong with the steps to build the image. It
breaks the CI for pulsar-client-cpp repo, as well as any other repo
that depends on the latest image. We should fix the image and push it
again.

[1] 
https://github.com/apache/pulsar-client-cpp/actions/runs/7078043224/job/19263093582?pr=360
[2] 
https://hub.docker.com/layers/apachepulsar/pulsar/3.0.2/images/sha256-5af72da140f3901bccc0a5b56de8764cd60f0d351011fd1b90c484a30889fbf8?context=explore

Thanks,
Yunze

[ANNOUNCE] Apache Pulsar Client C++ 3.4.1 released

[Yunze Xu]

The Apache Pulsar team is proud to announce Apache Pulsar Client C++
version 3.4.1.

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/client-cpp

API documents are at:
https://pulsar.apache.org/api/cpp/3.4.x/index.html

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

Regards,

The Pulsar Team

Re: [VOTE] Pulsar Client C++ Release 3.4.1 Candidate 2

[Yunze Xu]

Closing this vote by 3 binding +1s
- Penghui
- Yubiao
- Yunze

Thanks,
Yunze

On Sun, Nov 26, 2023 at 5:30 PM Yunze Xu  wrote:
>
> +1 (binding)
>
> - Verified the checksum and signatures
> - Built from source
> - Verified the pre-built binaries for arm64 on Ubuntu and macOS
> - Verified the Python client
>
> Thanks,
> Yunze
>
> On Fri, Nov 24, 2023 at 2:39 PM Yubiao Feng
>  wrote:
> >
> > +1 (binding)
> >
> > - Checked the signature
> > - Verified the MacOS arm64 pre-build binaries for produce and consume
> >
> > Thanks
> > Yubiao Feng
> >
> > On Tue, Nov 21, 2023 at 11:40 PM Yunze Xu  wrote:
> >
> > > This is the second release candidate for Apache Pulsar Client C++,
> > > version 3.4.1.
> > >
> > > It fixes the following issues:
> > > https://github.com/apache/pulsar-client-cpp/milestone/7?closed=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-client-cpp/pulsar-client-cpp-3.4.1-candidate-2/
> > >
> > > SHA-512 checksums:
> > >
> > > 2f8e88b7ead8f18065a51fe1c2df2c39f83334618bf664af5051391c6356e616626a5b7eed30813fe97dfa3408f93ffd5daaefc39470855df7b0bab4e80e4d76
> > >  apache-pulsar-client-cpp-3.4.1.tar.gz
> > >
> > > The tag to be voted upon:
> > > v3.4.0-candidate-2 (1c725b421c672549f2a34222b8cb740294e75ff1)
> > > https://github.com/apache/pulsar-client-cpp/releases/tag/v3.4.1-candidate-2
> > >
> > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > https://downloads.apache.org/pulsar/KEYS
> > >
> > > Please download the source package, and follow
> > >
> > > https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
> > > to compile and test.
> > >
> > > Note: If you're going to run the unit tests locally, please make sure
> > > the proxy is disabled.
> > >

Re: [VOTE] Pulsar Client C++ Release 3.4.1 Candidate 2

[Yunze Xu]

+1 (binding)

- Verified the checksum and signatures
- Built from source
- Verified the pre-built binaries for arm64 on Ubuntu and macOS
- Verified the Python client

Thanks,
Yunze

On Fri, Nov 24, 2023 at 2:39 PM Yubiao Feng
 wrote:
>
> +1 (binding)
>
> - Checked the signature
> - Verified the MacOS arm64 pre-build binaries for produce and consume
>
> Thanks
> Yubiao Feng
>
> On Tue, Nov 21, 2023 at 11:40 PM Yunze Xu  wrote:
>
> > This is the second release candidate for Apache Pulsar Client C++,
> > version 3.4.1.
> >
> > It fixes the following issues:
> > https://github.com/apache/pulsar-client-cpp/milestone/7?closed=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-client-cpp/pulsar-client-cpp-3.4.1-candidate-2/
> >
> > SHA-512 checksums:
> >
> > 2f8e88b7ead8f18065a51fe1c2df2c39f83334618bf664af5051391c6356e616626a5b7eed30813fe97dfa3408f93ffd5daaefc39470855df7b0bab4e80e4d76
> >  apache-pulsar-client-cpp-3.4.1.tar.gz
> >
> > The tag to be voted upon:
> > v3.4.0-candidate-2 (1c725b421c672549f2a34222b8cb740294e75ff1)
> > https://github.com/apache/pulsar-client-cpp/releases/tag/v3.4.1-candidate-2
> >
> > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > https://downloads.apache.org/pulsar/KEYS
> >
> > Please download the source package, and follow
> >
> > https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
> > to compile and test.
> >
> > Note: If you're going to run the unit tests locally, please make sure
> > the proxy is disabled.
> >

Re: [VOTE] DotPulsar Release 3.1.0 RC 1

[Yunze Xu]

+1 (binding)

- Verified checksum and signatures
- Built from source on macOS m1 and dotnet 8.0.100
- Verified an e2e example with the Nuget package

Thanks,
Yunze

On Mon, Nov 20, 2023 at 9:21 PM tison  wrote:
>
> Hi everyone,
>
> Please review and vote on the release candidate #1 for the version 3.1.0,
> as follows:
>
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
> This is the release candidate for DotPulsar, version 3.1.0.
>
> DotPulsar's KEYS file contains PGP keys we used to sign this release:
> https://downloads.apache.org/pulsar/KEYS
>
> Please download these packages and review this release candidate:
> - Review release notes
> - Download the source package (verify shasum, and asc) and follow the
> README.md to build and run DotPulsar.
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Source file:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-dotpulsar-3.1.0-rc-1/
>
> Nuget package:
> https://www.nuget.org/packages/DotPulsar/3.1.0-rc.1
>
> The tag to be voted upon:
> https://github.com/apache/pulsar-dotpulsar/tree/3.1.0-rc.1
>
> SHA-512 checksums:
> d96490c28be42707c906dfb2bba468b8880d6c4cbb76b13f6497e3ed3e9243d00ff778695f83442772ff7ccc2bad4afd6815b581f85281f81e4d6ba9afcd844b
> pulsar-dotpulsar-3.1.0-rc.1.tar.gz
>
> Best,
> tison.

[VOTE] Pulsar Client C++ Release 3.4.1 Candidate 2

[Yunze Xu]

This is the second release candidate for Apache Pulsar Client C++,
version 3.4.1.

It fixes the following issues:
https://github.com/apache/pulsar-client-cpp/milestone/7?closed=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-client-cpp/pulsar-client-cpp-3.4.1-candidate-2/

SHA-512 checksums:
2f8e88b7ead8f18065a51fe1c2df2c39f83334618bf664af5051391c6356e616626a5b7eed30813fe97dfa3408f93ffd5daaefc39470855df7b0bab4e80e4d76
 apache-pulsar-client-cpp-3.4.1.tar.gz

The tag to be voted upon:
v3.4.0-candidate-2 (1c725b421c672549f2a34222b8cb740294e75ff1)
https://github.com/apache/pulsar-client-cpp/releases/tag/v3.4.1-candidate-2

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

Please download the source package, and follow
https://github.com/apache/pulsar-client-cpp/wiki/Verify-the-candidate-release-in-your-local-env
to compile and test.

Note: If you're going to run the unit tests locally, please make sure
the proxy is disabled.

Re: PulsarMarker.proto throws error

[Yunze Xu]

I tried building on my Windows 11 via `mvn clean install -DskipTests
-Pcore-modules,-main` (the `-Pxxx` is to skip some modules like
connectors) and it worked well.
- java version "17.0.4" 2022-07-19 LTS
- Maven 3.8.6

I see your project directory is "C:\pulsar" and the lightproto plugin
will generate new Java files in a subdirectory. Did you have the write
permission on this directory?

Thanks,
Yunze

On Mon, Nov 20, 2023 at 8:53 PM Umut Bilal Okur  wrote:
>
> Hi, are there any one who can help me, please ?
> 
> Gönderen: Umut Bilal Okur 
> Gönderildi: 19 Kasım 2023 Pazar 18:06
> Kime: dev@pulsar.apache.org 
> Konu: PulsarMarker.proto throws error
>
> Hello folks,
>
> I'm pretty new here, while I were trying to run command "mvn clean install 
> -DskipTests" on project source code I got an error as below:
> [ERROR] Failed to execute goal 
> com.github.splunk.lightproto:lightproto-maven-plugin:0.4:generate (default) 
> on project pulsar-common: Failed to generate lightproto code for 
> [C:\pulsar\pulsar-common\src\main\proto\PulsarApi.proto, 
> C:\pulsar\pulsar-common\src\main\proto\PulsarMarkers.proto]: Failed to write 
> serializer for field: uınt64 -> [Help 1].
>
> I couldn't figure out why it happens, I'm on a Windows machine, I wonder if 
> that is the reason.
>
> Many thanks in advance.

Re: [VOTE] Pulsar Client C++ Release 3.4.1 Candidate 1

[Yunze Xu]

Thanks for your feedback. I will fix this regression and this vote is cancelled.

Thanks,
Yunze

On Mon, Nov 20, 2023 at 4:17 PM Baodi Shi  wrote:
>
> Hi, yunze.
>
> When I test producer flush method for C client.
>
> I get two callbacks. If the user releases the context in the callback
> method, they will encounter a segmentation fault.
>
> Refer to: https://github.com/apache/pulsar-client-cpp/issues/352
>
>
> Thanks,
> Baodi Shi
>
>
> On Nov 18, 2023 at 00:02:55, Yunze Xu  wrote:
>
> > This is the first release candidate for Apache Pulsar Client C++, version
> > 3.4.1.
> >
> > It fixes the following issues:
> > https://github.com/apache/pulsar-client-cpp/milestone/7?closed=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-client-cpp/pulsar-client-cpp-3.4.1-candidate-1/
> >
> > SHA-512 checksums:
> >
> > 74ff4bbc9126f30eb8c104342918b577d4cdf62a443593b7caf89ef8f8e9dec57c4c66bbcb3965186780b0fdf1a40172d8a941584ceb3db798773b119b0f2c72
> > apache-pulsar-client-cpp-3.4.1.tar.gz
> >
> > The tag to be voted upon:
> > v3.4.1-candidate-1 (e6ec207cd857af149b21429530be0691bd26dbdb)
> > https://github.com/apache/pulsar-client-cpp/releases/tag/v3.4.1-candidate-1
> >
> > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > https://downloads.apache.org/pulsar/KEYS
> >
> > Please download the source package, and follow the README to compile and
> > test.
> >
> > Note: If you're going to run the unit tests locally, please make sure
> > the proxy is disabled.
> >

[VOTE] Pulsar Client C++ Release 3.4.1 Candidate 1

[Yunze Xu]

This is the first release candidate for Apache Pulsar Client C++, version 3.4.1.

It fixes the following issues:
https://github.com/apache/pulsar-client-cpp/milestone/7?closed=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-client-cpp/pulsar-client-cpp-3.4.1-candidate-1/

SHA-512 checksums:
74ff4bbc9126f30eb8c104342918b577d4cdf62a443593b7caf89ef8f8e9dec57c4c66bbcb3965186780b0fdf1a40172d8a941584ceb3db798773b119b0f2c72
 apache-pulsar-client-cpp-3.4.1.tar.gz

The tag to be voted upon:
v3.4.1-candidate-1 (e6ec207cd857af149b21429530be0691bd26dbdb)
https://github.com/apache/pulsar-client-cpp/releases/tag/v3.4.1-candidate-1

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

Please download the source package, and follow the README to compile and test.

Note: If you're going to run the unit tests locally, please make sure
the proxy is disabled.

Re: [Discuss] Release Pulsar C++ Client 3.4.1

[Yunze Xu]

There is another critical issue introduced by 3.4.0:
https://github.com/apache/pulsar-client-python/issues/162

I will open another fix for it.

Thanks,
Yunze

On Thu, Nov 16, 2023 at 12:45 PM Yunze Xu  wrote:
>
> In the latest C++ Client 3.4.0 release, we observed a regression
> https://github.com/apache/pulsar-client-cpp/issues/346. It's a
> critical bug that a crash could happen for each reconnection.
>
> I pushed a fix (https://github.com/apache/pulsar-client-cpp/pull/347).
> After it's merged, I will start the release process for 3.4.1.
>
> Please let me know if you have any questions.
>
> Thanks,
> Yunze

Re: [VOTE] PIP-303: Add optional parameters for getPartitionedStats

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Thu, Nov 16, 2023 at 11:01 AM Jie crossover  wrote:
>
> Hi All, This thread is to start a vote for PIP-303. PIP:
> https://github.com/apache/pulsar/pull/21228 Discussion thread:
> https://lists.apache.org/thread/c92043zq6lyrsd5z1hnln48mx858n7vj
> --
> Best Regards！
> crossoverJie

[Discuss] Release Pulsar C++ Client 3.4.1

[Yunze Xu]

In the latest C++ Client 3.4.0 release, we observed a regression
https://github.com/apache/pulsar-client-cpp/issues/346. It's a
critical bug that a crash could happen for each reconnection.

I pushed a fix (https://github.com/apache/pulsar-client-cpp/pull/347).
After it's merged, I will start the release process for 3.4.1.

Please let me know if you have any questions.

Thanks,
Yunze

[ANNOUNCE] Apache Pulsar Client C++ 3.4.0 released

[Yunze Xu]

The Apache Pulsar team is proud to announce Apache Pulsar Client C++
version 3.4.0.

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 C++ client release details and downloads, visit:
https://pulsar.apache.org/download/#pulsar-c-client

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

API documents are at:
https://pulsar.apache.org/api/cpp/3.4.x/index.html

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

Regards,

The Pulsar Team