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
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
-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,
I am sure that this is a good idea.
-1 (binding)
I will follow up on the discussion thread
I am sorry I am catching up late on this thread
Enrico
Il giorno lun 9 gen 2023 alle ore 03:51 Ran Gao ha scritto:
>
> +1 (non-binding)
>
> Thanks,
> Ran Gao
>
> On 2023/01/08 15:05:31 Zixuan Liu wrote:
+1 (non-binding)
Thanks,
Ran Gao
On 2023/01/08 15:05:31 Zixuan Liu wrote:
> +1 (non-binding)
>
> Thanks,
> Zixuan
>
> Yunze Xu 于2023年1月8日周日 22:38写道：
>
> > +1 (binding)
> >
> > Thanks,
> > Yunze
> >
> > On Sun, Jan 8, 2023 at 4:46 PM Zike Yang wrote:
> > >
> > > +1 (non-binding)
> > >
> > > T
+1 (non-binding)
Thanks,
Zixuan
Yunze Xu 于2023年1月8日周日 22:38写道：
> +1 (binding)
>
> Thanks,
> Yunze
>
> On Sun, Jan 8, 2023 at 4:46 PM Zike Yang wrote:
> >
> > +1 (non-binding)
> >
> > Thanks,
> > Zike Yang
> >
> > On Sun, Jan 8, 2023 at 3:22 PM Haiting Jiang
> wrote:
> > >
> > > +1 binding
> >
+1 (binding)
Thanks,
Yunze
On Sun, Jan 8, 2023 at 4:46 PM Zike Yang wrote:
>
> +1 (non-binding)
>
> Thanks,
> Zike Yang
>
> On Sun, Jan 8, 2023 at 3:22 PM Haiting Jiang wrote:
> >
> > +1 binding
> >
> > Although I think we should use more unique keys for system properties in
> > pulsar,
> > e.
+1 (non-binding)
Thanks,
Zike Yang
On Sun, Jan 8, 2023 at 3:22 PM Haiting Jiang wrote:
>
> +1 binding
>
> Although I think we should use more unique keys for system properties in
> pulsar,
> e.g. reserve all properties prefixed with "PULSAR_" for system internal usage.
> But it's another topic
+1 binding
Although I think we should use more unique keys for system properties in pulsar,
e.g. reserve all properties prefixed with "PULSAR_" for system internal usage.
But it's another topic as we already have "RECONSUMETIMES".
On Sun, Jan 8, 2023 at 12:27 PM Nitin Goyal wrote:
>
> Hello com
Hello community,
I'm starting the VOTE for PIP-239: Retry Mechanism per Message title.
Motivation: We are working on a project where each message has their retry
as per the requirements. like one message 100 times and other messages 5
times and so on. This feature also adds an extra functionality
13 matches
Mail list logo
