Re: [VOTE] Pulsar Node.js Client Release 1.3.2 Candidate 1
+1 (binding) * check the license headers * install the npm package * build the source and run producer/consumer * verify checksum and signatures == Hiroyuki Sakai Yahoo Japan Corp. E-mail: hsa...@yahoo-corp.jp From: Masahiro Sakamoto Sent: Tuesday, October 12, 2021 19:20 To: dev@pulsar.apache.org Subject: [VOTE] Pulsar Node.js Client Release 1.3.2 Candidate 1 This is the first release candidate for Apache Pulsar Node.js client, version 1.3.2. The artifacts are exactly the same as the first vote, but I didn't upload them and the signature to the staging repository of dist, so I'll run the vote again. It fixes the following issues: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fpulsar-client-node%2Fmilestone%2F9%3Fclosed%3D1&data=04%7C01%7Chsakai%40yahoo-corp.jp%7C4a5fbeef1feb41c8dba008d98d69e986%7Ca208d369cd4e4f87b11998eaf31df2c3%7C1%7C0%7C637696308286014946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oLRNjDYhsxVVk8Kogk02xdzuf4pFAy0o1lVr6D4XoQA%3D&reserved=0 *** 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), the npm package is provided for convenience. Source files: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fpulsar%2Fpulsar-client-node-1.3.2-candidate-1%2F&data=04%7C01%7Chsakai%40yahoo-corp.jp%7C4a5fbeef1feb41c8dba008d98d69e986%7Ca208d369cd4e4f87b11998eaf31df2c3%7C1%7C0%7C637696308286014946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=G3nUXdGEURAggprO8HaBHeU0liFKsoWoSuX%2BtoAwTDM%3D&reserved=0 SHA-512 checksum: 5f6c7e1a096a3ae66eee71c552af89532ed86bf94da3f3d49836c080426ee5dcaabeda440a989d51772d2e67e2dca9539ea83cfbc7c2a0847a0ec04b310f v1.3.2-rc.1.tar.gz The tag to be voted upon: v1.3.2-rc.1 https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fpulsar-client-node%2Freleases%2Ftag%2Fv1.3.2-rc.1&data=04%7C01%7Chsakai%40yahoo-corp.jp%7C4a5fbeef1feb41c8dba008d98d69e986%7Ca208d369cd4e4f87b11998eaf31df2c3%7C1%7C0%7C637696308286014946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5oYDqIM%2F4KXxRTqeLyPC0HkFrRrlXbC5MyJ6AQlIW2c%3D&reserved=0 The npm package: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.npmjs.com%2Fpackage%2Fpulsar-client%2Fv%2F1.3.2-rc.1&data=04%7C01%7Chsakai%40yahoo-corp.jp%7C4a5fbeef1feb41c8dba008d98d69e986%7Ca208d369cd4e4f87b11998eaf31df2c3%7C1%7C0%7C637696308286014946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pIxUjZagd50cFITp9JFAXuF9W0dFfudkaNDN%2BkT6a1k%3D&reserved=0 Pulsar's KEYS file containing PGP keys we use to sign the release: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fpulsar%2FKEYS&data=04%7C01%7Chsakai%40yahoo-corp.jp%7C4a5fbeef1feb41c8dba008d98d69e986%7Ca208d369cd4e4f87b11998eaf31df2c3%7C1%7C0%7C637696308286014946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5s2Vi%2BdWAcmsyWbmH8nD65GBxG4K3I6jheC4%2BYTA8j4%3D&reserved=0 Please download the source files, and follow the README to build and run the Pulsar Node.js client. Masahiro Sakamoto Yahoo Japan Corp. E-mail: massa...@yahoo-corp.jp
[GitHub] [pulsar-manager] ericsyh opened a new issue #426: [bug](topics) Topics unsubscribe failed on pulsar-manager
ericsyh opened a new issue #426: URL: https://github.com/apache/pulsar-manager/issues/426 ### Background After the test, we found that topics unsubscribe function didn't work on pulsar-manager while pulsar-admin executes the same subscription work as expected. This should be a bug on Pulsar Manger. https://user-images.githubusercontent.com/10498732/137270788-437746cf-a8a3-47a3-b2dc-c94a281f5f54.png";> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[Issue 12271][Modernizer] Add Maven Modernizer plugin in pulsar-proxy module
Hello everyone, I have opened a PR in which I have added the Maven Modernizer plugin in the pulsar-proxy module to enforce we move away from legacy APIs. I have fixed all violations. I would request you to please review my PR https://github.com/apache/pulsar/pull/12326 Thanks, Amar Prakash Pandey
Python module Pulsar-client 2.8.1 issue
hi.Plusar Devs: I'm using The Pulsar-client 2.8.1 module in Python, but I find that the client memory will not be freed every time I create or close producers using producer. Is there any way to solve this problem?
Re: Python module Pulsar-client 2.8.1 issue
Hi, do you have a code example to demonstrate the problem? -- Matteo Merli On Thu, Oct 14, 2021 at 8:59 AM 袁滔 <609101...@qq.com.invalid> wrote: > > hi.Plusar Devs: > I'm using The Pulsar-client 2.8.1 module in Python, but > I find that the client memory will not be freed every time I create or close > producers using producer. Is there any way to solve this problem?
Re: [Issue 12271][Modernizer] Add Maven Modernizer plugin in pulsar-proxy module
Amar, Thanks for your contribution I approved your PR, waiting for another reviewer Cheers Enrico Il Gio 14 Ott 2021, 13:52 Amar Prakash Pandey ha scritto: > Hello everyone, > > I have opened a PR in which I have added the Maven Modernizer plugin in > the pulsar-proxy module to enforce we move away from legacy APIs. I have > fixed all violations. > > I would request you to please review my PR > https://github.com/apache/pulsar/pull/12326 > > Thanks, > Amar Prakash Pandey > >
Re: Release 2.9.0....adding more PRs ? please don't
Hello, Enrico: In version 2.9.0, do we need to consider whether transaction-related features can be used in a production environment? This feature is expected by many users. So do you need to consider the progress of transaction-related stability. -- Thanks Xiaolong Ran Enrico Olivelli 于2021年10月12日周二 下午2:58写道： > Hello, > I see that someone is adding PRs to Milestone 30 (Pulsar 2.9.0) > > we are pretty late on starting the release > https://github.com/apache/pulsar/milestone/30 > > If you have a PR that you really want to see in 2.9.0 please look after it > and ensure that it has: > - CI passing > - no "Request changes" or negative comments to be discussed > - enough reviews > > I will cut the RC0 tomorrow morning, CEST timezone. > > We already have a good amount of new features and fixes in 2.9.0, it is > enough to cut a release. > Pending PRs that are not blockers for a release can be delivered on the > next release. > > Best regards > Enrico Olivelli >
Re: [VOTE] PIP - Support pluggable entry filter in Dispatcher
+1 (non-binding) -- Thanks Xiaolong Ran PengHui Li 于2021年10月14日周四 上午11:58写道： > +1 (binding) > > Penghui > > On Wed, Oct 13, 2021 at 5:19 PM Hang Chen wrote: > > > +1 (binding) > > > > Good job! > > > > Thanks, > > Hang > > > > Enrico Olivelli 于2021年10月13日周三 下午5:04写道： > > > > > > +1 (binding) > > > > > > great work ! > > > > > > Enrico > > > > > > Il giorno mer 13 ott 2021 alle ore 08:34 linlin ha > > > scritto: > > > > > > > Hi Pulsar Community, > > > > > > > > I would like to start a VOTE for PIP - Support pluggable entry filter > > in > > > > Dispatcher. > > > > > > > > The issue for this PIP is here: > > > > https://github.com/apache/pulsar/issues/12269 > > > > > > > > Please VOTE within 72 hours. > > > > > > > > Thanks, > > > > Lin Lin > > > > > > >
Re: [PROPOSAL] Support level increment delay for ReconsumerLater interface
Thanks Penghui and Chris for the feedback.
At present, the introduction of the ReconsumerLater interface itself is
rather confusing, so we may abandon the ReconsumeLater-related interface in
later version iterations. But the backoff and retry function for messages
is indeed a scenario that users need. So we consider an automatic backoff
retry strategy based on the current Nack logic. In addition to supporting
the default automatic retry strategy, we can also expose a NackPolicy
interface to support users to customize their own backoff retry strategy
--
Thanks
Xiaolong Ran
r...@apache.org 于2021年9月29日周三 上午11:46写道：
> > 1. The new API looks very similar to the existing delay-queue based
> > implementation but It's very different in nature, which might confuse
> users.
>
> Hello PenghuiLi:
>
> In response to this problem, I am also a bit confused. The current
> implementation of ReconsumerLater is also the solution of calling
> DelayMessage. This PIP is an enhancement of the current ReconsumerLater, so
> the implementation here is whether we continue to use DelayMessage or we
> Repackage Time Tracker by yourself, stripping a clean API interface.
>
> --
>
> Thanks
> Xiaolong Ran
>
> PengHui Li 于2021年9月28日周二 下午4:02写道：
>
>> Hi Xiaolong,
>>
>> Currently, in the Pulsar client, we have ack timeout, negative ack, and
>> reconsume later method to achieve diverse message redelivery requirements.
>> I agree with the client side flexible message redelivery controlling but I
>> have a few concerns with the new API.
>>
>> 1. The new API looks very similar to the existing delay-queue based
>> implementation but It's very different in nature, which might confuse
>> users.
>> 2. Does the redelivery level can be specified by users? In my opinion, we
>> can provide a default exponentially backed off policy for users and we'd
>> better support customize it.
>> 3. I think if make some enhancements for the ack timeout is more
>> reasonable, the ack timeout handling will not use the delay queue such as
>> we have an AckTimePolicy there
>> And by default, we can support an ExponentiallyBackoffAckTimePolicy,
>> and XXXAckTimeoutPolicy and YYYAckTimeoutPolicy can be implemented by
>> users.
>>
>> Thanks,
>> Penghui.
>>
>> On Fri, Sep 10, 2021 at 4:33 PM r...@apache.org
>> wrote:
>>
>> > Hello everyone:
>> >
>> > I wrote a proposal to enhance the functionality of ReconsumeLater, the
>> > specific content is as follows:
>> >
>> > ---
>> >
>> > # PIP 94: Support level increment delay for ReconsumerLater interface
>> >
>> > - Status: Draft
>> > - Author: Xiaolong Ran
>> > - Pull request:
>> > - Mailing list discussion:
>> > - Release:
>> >
>> > The purpose of this proposal is mainly to add ReconsumerLater on the
>> > consumer side to retry in an incremental level
>> >
>> > ## Motivation
>> >
>> > At present, ReconsumrLater only supports specifying a specific delay
>> time
>> > for distribution processing. The usage is as follows:
>> >
>> > ```
>> > while (true) {
>> > Message msg = consumer.receive();
>> >
>> > try {
>> > // Process message...
>> >
>> > consumer.acknowledge(msg);
>> > } catch (Throwable t) {
>> > log.warn("Failed to process message");
>> > consumer.reconsumeLater(msg, 1000 , TimeUnit.MILLISECONDS);
>> > }
>> > }
>> > ```
>> >
>> > Its implementation principle is to use Pulsar's built-in delay message
>> to
>> > pass in the specified time as the parameter
>> > of deliverAfter(), and then push the message to the consumer side again
>> > after the time arrives.
>> >
>> > This is a good idea, which allows users to flexibly define their own
>> delay
>> > time in a specific scenario. But assuming
>> > that the message is not processed correctly within the time specified by
>> > the user, the behavior of ReconsumerLater has
>> > ended at this time. Whether we can consider adding a retry scheme
>> according
>> > to the time level. Then when the first
>> > specified time range is not processed correctly, ReconsumerLater() can
>> > automatically retry according to the time level
>> > until the user correctly processes the specific message.
>> >
>> > ## Implementation
>> >
>> > As mentioned above, if we can here follow a certain delay level from
>> low to
>> > high and allow it to automatically retry,
>> > it is a more user-friendly way. For example, we can define the following
>> > delay level:
>> >
>> > ```
>> > MESSAGE_DELAYLEVEL = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m
>> 30m
>> > 1h 2h"
>> > ```
>> >
>> >
>> > In this PIP, we mainly introduce two new API interfaces to users:
>> >
>> > 1. Specify the delay level
>> >
>> > ```
>> > reconsumeLater(Message message, int delayLevel)
>> > ```
>> >
>> > This implementation method is consistent with the current reconsumeLater
>> > interface, but instead of specifying the
>> > delay level, specify the specific delay time. For example, level `1`
>> > corresponds to `1s`, and level `3` corresponds to `10s`.
>
