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 to the same consumer. but the retry will allow adding custom delay to the message and the same msg can be processed by another consumer from the same consumer group as per their configuration (i.e. shared types). 2. If a message is NACKed the message will get consumed infinite time based on backoff limit till it gets ACKed. where a reconsume later message will be sent to DLQ onces it reaches the retry limit set by the consumer. 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. On Tue, Jan 10, 2023 at 6:53 PM r...@apache.org <ranxiaolong...@gmail.com> wrote: > -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 > > > > > > > > > > > > -- Regards Nitin Goyal
