-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, it seems that there is not much difference between the two. So how do we advise users under what circumstances? It is more appropriate to use ReconsumeLater, and under what circumstances is it more appropriate to use Nack? For me, I don't know how to introduce it to users. I can only explain it based on their implementation logic. ReconsumeLater sends messages to the Retry Topic, and Nack sends messages to the DLQ Topic. But Nack can completely replace the logic here. Is it necessary for us to introduce a new ReconsumeLater interface to confuse users.
So here I hope we can discuss whether we need to support this feature or logic from the perspective of Nack. -- Thanks Xiaolong Ran Enrico Olivelli <eolive...@gmail.com> 于2023年1月9日周一 15:36写道： > 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 <r...@apache.org> ha > scritto: > > > > +1 (non-binding) > > > > Thanks, > > Ran Gao > > > > On 2023/01/08 15:05:31 Zixuan Liu wrote: > > > +1 (non-binding) > > > > > > Thanks, > > > Zixuan > > > > > > Yunze Xu <y...@streamnative.io.invalid> 于2023年1月8日周日 22:38写道： > > > > > > > +1 (binding) > > > > > > > > Thanks, > > > > Yunze > > > > > > > > On Sun, Jan 8, 2023 at 4:46 PM Zike Yang <z...@apache.org> wrote: > > > > > > > > > > +1 (non-binding) > > > > > > > > > > Thanks, > > > > > Zike Yang > > > > > > > > > > On Sun, Jan 8, 2023 at 3:22 PM Haiting Jiang < > jianghait...@gmail.com> > > > > 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 as we already have "RECONSUMETIMES". > > > > > > > > > > > > > > > > > > On Sun, Jan 8, 2023 at 12:27 PM Nitin Goyal < > nitin.goyal....@gmail.com> > > > > wrote: > > > > > > > > > > > > > > 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 > while > > > > > > > comparing existing queueing services like RabbitMQ or SQS etc. > > > > > > > > > > > > > > For more details please find the detailed PIP at: > > > > > > > https://github.com/apache/pulsar/issues/19136 > > > > > > > > > > > > > > Discussion Threads: > > > > > > > 1. > https://lists.apache.org/thread/rn6114xxtx1j57yy2jbmdv4xzt80o1hz > > > > > > > 2. > https://lists.apache.org/thread/b9rfv6t307z439xx3zt2ym4p140qzp06 > > > > > > > > > > > > > > Proposed changes in pulsar go client library. > > > > > > > https://github.com/apache/pulsar-client-go/pull/939 > > > > > > > > > > > > > > Thanks > > > > > > > Nitin Goyal > > > > > > > >
