Hi Pulsar Community,
I am continuing work to clean up the authorization code base. I
noticed we have several methods on the AuthorizationProvider interface
that have been annotated as deprecated since 2.7.0. They are unused
and clutter the interface. I propose we remove them. The only risk is
to u
Hello kmter:
For subscription-level indicators, I think we can collect and record them
in Prometheus. The only thing to note here is that the subscription-level
indicators may have a large number of indicators in a specific business
scenario, which will have a certain impact on the indicator colle
Hi Pulsar Community,
While reviewing the AuthorizationService, I noticed we have 4 methods
that are unused and that block internally. Given the acceptance of PIP
149, I think we should deprecate and eventually remove these methods.
We cannot get rid of them yet because users with custom plugins ma
+1（non-binding）
In the Go SDK, we expose the interface for obtaining related properties to
the user in the MessageID struct. Yes, as mentioned, developers of Pulsar
core need to use these field features to do some related operations.
--
Thanks
Xiaolong Ran
Enrico Olivelli 于2023年1月11日周三 06:51写道：
+1 (binding)
Please highlight the limitations of using RocksDB as metastore in the
standalone service.
Thanks,
Hang
Enrico Olivelli 于2023年1月10日周二 15:59写道：
>
> Il giorno mar 10 gen 2023 alle ore 07:18 guo jiwei
> ha scritto:
> >
> > Thank you all,
> >
> > Close the vote with 5 bindings(PengHui,
Congratulations, Yunze!
Best,
Hang
Nitin Goyal 于2023年1月10日周二 23:09写道：
>
> Congratulations! Yunze
>
> Best
> Nitin Goyal
>
> On Tue, Jan 10, 2023 at 6:06 PM r...@apache.org
> wrote:
>
> > Congrats! Yunze
> >
> > Ruguo Yu 于2023年1月10日周二 09:32写道：
> >
> > > Congratulations, Yunze!
> > >
> > > On 20
+1 (binding)
Enrico
Il Mar 10 Gen 2023, 18:01 guo jiwei ha scritto:
> +1 (binding)
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Fri, Dec 23, 2022 at 11:01 AM PengHui Li wrote:
>
> > +1(binding)
> >
> > Thanks,
> > Penghui
> >
> > On Fri, Dec 23, 2022 at 10:31 AM 丛搏 wrote:
> >
> > > +1 (non-binding
I noticed last night this PR - https://github.com/apache/pulsar-site/pull/349
I’m not sure about these changes and such changes to our project front page
should have as many eyes on them as possible.
Please discuss and approve or comment before merging this PR!
Thank you,
Dave
+1 (binding)
Regards
Jiwei Guo (Tboy)
On Fri, Dec 23, 2022 at 11:01 AM PengHui Li wrote:
> +1(binding)
>
> Thanks,
> Penghui
>
> On Fri, Dec 23, 2022 at 10:31 AM 丛搏 wrote:
>
> > +1 (non-binding)
> >
> > Thanks,
> > Bo
> >
> > Yunze Xu 于2022年12月22日周四 20:34写道：
> > >
> > > Hi all,
> > >
> > > I
Hello all,
I am extremely apologies about the discussion hours. It was my first time
to have discussions and voting process and wasn’t aware about the policy.
Will keep this in mind from next time.
Once again apologies.
Sincere
Nitin Goyal
On Tue, 10 Jan 2023 at 10:04 PM, Dave Fisher wrote:
-1 (binding) because the discussion thread is in progress and most important
you only allowed for 71 hours of discussion.
I think it is important that any change to the main producer / consumer flow be
proven to have no performance regressions in the broker.
Regards,
Dave
> On Jan 8, 2023, at
Congratulations! Yunze
Best
Nitin Goyal
On Tue, Jan 10, 2023 at 6:06 PM r...@apache.org
wrote:
> Congrats! Yunze
>
> Ruguo Yu 于2023年1月10日周二 09:32写道：
>
> > Congratulations, Yunze!
> >
> > On 2022/12/29 12:42:36 Haiting Jiang wrote:
> > > Hi all,
> > >
> > > The Apache Pulsar Project Management
Hello Xiaolong Ran,
Thanks for clarification.
>> about subsequent version iterations, i would like to discuss with you
whether we want discard the logic of ReconsumeLater
We can open a new PIP/discussion thread for it. And there we can consider
all types of scenarios related to i.e. retry, dlq,
Hi Nitin:
> 3. if a message NACKed then. How many times it retries is also in memory
if
> the consumer has failed or restarted all this information is lost. But in
> the case of reconsumeLater all these things persisted in the broker.
The RedeliverCount field is an attribute in the CommandMessage
Hello Xiaolong,
About your concern on NACK and reconsumeLater. Also as per current
Architecture rheir work is completely different from each other. which is
as follows.
1. NACK does not send messages to DLQ as per current architecture.; it
keeps messages in consumer memory to redeliver them later
Hello Team,
Thanks for pointing these things out.
First thing is to consider that this addon feature is for the message which
needs to go to DLQ after a retryLater reaches the maximum limit of consumer
level retries. It allows an additional maximum limit if a message has one
at the time of produc
-1(non-binding)
As discussed in [DISCUSS], for ReconsumeLater, I prefer to discard this
interface in later versions, and think about this issue from another angle.
>From a user’s point of view, both ReconsumeLater and Nack have the function
of retweeting messages. From a functional point of view,
Hello Lari:
Here I actually want to discuss whether it is necessary for us to introduce
Jackson modules, and what is the scope boundary we use when introducing
Jackson modules? Here are some questions about this:
1. After we introduce Jackson modules, do we need to optimize the code that
origina
Congrats! Yunze
Ruguo Yu 于2023年1月10日周二 09:32写道：
> Congratulations, Yunze!
>
> On 2022/12/29 12:42:36 Haiting Jiang wrote:
> > Hi all,
> >
> > The Apache Pulsar Project Management Committee (PMC) has invited Yunze Xu
> > (https://github.com/BewareMyPower) as a member of the PMC and we are
> > ple
Thanks for submitting this PIP, Nitin Goyal.
Seeing that you have submitted a related pull request in the Go SDK
community, I am sorry that I made the request changes first.
For the retry processing of a single message, the methods currently
provided are:
-ReconsumeLater
-Nack
In actual usage s
Hi Zike,
Thank you for clarifying the issues.
Sounds good if we can remove dependency on SVN.
> In addition, I suddenly thought that we also needed to upload the npm
package file `pulsar-client-1.X.0.tgz` to the SVN repo during the
release process. This file could be generated from `npm pack` com
I think that Michael's point is very important.
Producers and Consumers are decoupled and this PIP would introduce
a new concept.
Also the same Message can be consumed using multiple subscriptions
(typically Applications)
and all the applications will process the message in a different way
(by def
22 matches
Mail list logo
