Re: [DISCUSS] We must change the way we review PIPs
+1 (non-binding) On Fri, 31 Mar, 2023, 08:41 Jun Ma, wrote: > +1. > > Besides using a single source to lift the review efficiency, adding > control over the design documents is also a good practice from the project > management perspective. > > > Best, > Jun > > From: Yunze Xu > Sent: Friday, March 31, 2023 10:44 > To: dev@pulsar.apache.org > Subject: Re: [DISCUSS] We must change the way we review PIPs > > +1 to me. Once the discussion thread of a PIP became too long, it > would be hard to continue the discussion. > > Thanks, > Yunze > > On Fri, Mar 31, 2023 at 9:13 AM PengHui Li wrote: > > > > +1 for creating a folder named "pip" in the main pulsar repo > > So far, it is good enough to solve the problems we've had. > > > > If it is really worth moving to another repo in the future. > > We can move it maybe 3, 5 years later. > > > > Thanks, > > Penghui > > > > > > On Fri, Mar 31, 2023 at 8:29 AM tison wrote: > > > > > Hi Asaf, > > > > > > Thanks for starting this thread! > > > > > > I have similar thoughts on using a single source for reviewing PIPs. > GH PRs > > > are good for conversation, although multiple conversations are still > hard > > > to follow (which can be natural) > > > > > > Here is how Rust does it[1] - a self-documented RFC repo + review PRs + > > > tracking issue on the main repo once accepted. > > > > > > Here is what I designed for TiDB[2][3]; proposals are placed in a > folder > > > under the main repo. > > > > > > We don't have to follow other community's ways, but these two practices > > > seem good to read. > > > > > > And, to follow the ASF voting strategy[4][5], we may still need a > standard > > > vote mail thread and document the result on the mailing list. > > > > > > Best, > > > tison. > > > > > > [1] https://github.com/rust-lang/rfcs > > > [2] https://github.com/pingcap/tidb/tree/master/docs/design > > > [3] > > > > > > > https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html > > > [4] https://www.apache.org/foundation/voting.html > > > [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy > > > > > > > > > Girish Sharma 于2023年3月31日周五 04:33写道： > > > > > > > +1 (non-binding .. ? ) > > > > I've already commented a couple of times (here and there) that the > > > process > > > > needs to be consolidated at a single place. This is a good and > detailed > > > > approach. > > > > Not sure if there is a historical context behind keeping the > discussion > > > in > > > > dev mailing list.. > > > > > > > > Regards > > > > > > > > On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika > > > wrote: > > > > > > > > > Hi all, > > > > > > > > > > In the last 2 months, I've increased my PIP review time (I do it in > > > > > cycles), and reviewed quite a few PIPs. > > > > > > > > > > My conclusion as a result of that: > > > > > > > > > > It's nearly impossible to review PIPs using a mailing list. > > > > > We must fix it soon. > > > > > > > > > > *Why?* > > > > > 1. Let's say you review the PIP and find 10 issues. Once you quote > and > > > > > comment on those ten points, you basically started 10 threads of > > > > > conversations. > > > > > After 2-3 ping pongs with quotes of quotes of quotes, it takes you > > > > forever > > > > > to read each thread properly. You find your CTRL-F to search to > find > > > your > > > > > original quote, and reply. Load it up again in your head, > switching to > > > > the > > > > > PIP tab to read it again. > > > > > After 10 ping pongs, it becomes almost an impossible mission. > > > > > > > > > > I can say I'm 75% tired just from the process, not from the review > > > > itself. > > > > > > > > > > 2. It's non collaborative by design. > > > > > After 10 ping pongs, the ability of someone to come and join the > > > > discussion > > > > > is 0. They need to go through so many replies, which are half > quotes, > > > > find > > > > > the original reply, and browse to the PIP. > > > > > It's no wonder people drop off the PIP review once we cross 5-6 > > > replies. > > > > > It's no wonder, nobody joins after 10 replies. > > > > > > > > > > 3. It's not open to the public. Non collaborative. > > > > > You can't just get a link, and join the review. Not only because > of (1) > > > > and > > > > > (2). You need to join the mailing list. You don't get the past > emails > > > to > > > > > reply. Just joining the list is a high enough bar for many people. > > > > > I personally participated in review of proposals in OpenTelemetry > in > > > the > > > > > last 6 months, even though I'm just an occasional user. Why? They > were > > > > > conducted on GitHub PR , so it was easy for me - click a link and > > > reply. > > > > > > > > > > 4. All over the place > > > > > Sometimes people comment on the GitHub issue. > > > > > Sometimes on the mailing list. > > > > > Not a single place. > > > > > > > > > > 5. No history. > > > > > Ok, finally the author was convinced. I can't see just the changes. > > >
Re: [Vote] PIP-242: Introduce enableStrictTopicName to reject creating topic with -partition- keyword.
+1 (non-binding) On Tue, Jan 31, 2023 at 12:29 PM guo jiwei wrote: > +1 (binding) > > > Regards > Jiwei Guo (Tboy) > > On Tue, Jan 31, 2023 at 2:36 PM Yunze Xu > wrote: > > > > +1 (binding) > > > > Thanks, > > Yunze > > > > On Tue, Jan 31, 2023 at 6:57 AM wrote: > > > > > > Hello everyone. > > > > > > I would like to start the vote for PIP-242 > https://github.com/apache/pulsar/issues/19239, > > > Please let me know if you have any concerns or questions. > > > > > > Best, > > > Mattison > > > > > > --- Paste original PIP content to help quote -- > > > > > > ### Motivation > > > > > > Currently, the Apache Pulsar broker allows users to create a topic > name that includes `-partition-`, which is confusing for our developers to > identify whether this is a partition of a partitioned topic. Plus, we need > to add more logic to be compatible with this special topic name. for > example: > > > > > > - https://github.com/apache/pulsar/pull/19240 > > > - https://github.com/apache/pulsar/pull/19230 > > > - https://github.com/apache/pulsar/pull/19171 > > > - https://github.com/apache/pulsar/pull/19086 > > > - ... > > > > > > ### Goal > > > This proposal wants `-partition-` to be a topic name keyword. Users > can only create a topic with it if the topic is partitioned. For the > compatibility reason, we want to Introduce a new configuration - > `enableStrictTopicName` for the broker to help reject creating a topic in > the following cases: > > > 1. Create a partitioned topic that includes `-partition-`. > > > 2. Create a topic which is not a partitioned topic. > > > > > > **Create a topic:** > > > _no corresponding partitioned topic_ > > > > > > - persistent://public/default/local-name (passed) > > > - persistent://public/default/local-name-partition-z (rejected by > keyword) > > > - persistent://public/default/local-name-partition-0 (rejected by > keyword) > > > > > > _Has corresponding partitioned topic, **partitions=2** and topic > partition name is **persistent://public/default/local-name**_ > > > > > > - persistent://public/default/local-name-partition-0 (passed, Because > it is the partition topic's sub-partition) > > > - persistent://public/default/local-name-partition-z (rejected by > keyword) > > > - persistent://public/default/local-name-partition-4 (rejected, > Because it exceeds the number of maximum partitions) > > > > > > **Create a partitioned topic(topic metadata)** > > > > > > - persistent://public/default/local-name (passed) > > > - persistent://public/default/local-name-partition-z (rejected by > keyword) > > > - persistent://public/default/local-name-partition-0 (rejected by > keyword) > > > > > > > > > ### API Changes > > > > > > Add a new configuration, `enableStrictTopicName=false`. > > > > > > ### Implementation > > > > > > 1. Add configuration `enableStrictTopicName=false`. > > > 2. Add rejection logic when the user enables `enableStrictTopicName`. > > > 4. Add warning logs to inform users that we do not recommend creating > non-partitioned topics with the keyword `-partition-`. > > > 5. Make `enableStrictTopicName=true` in the next major release. > -- Regards Nitin Goyal
Re: [ANNOUNCE] Bo Cong as new PMC member in Apache Pulsar
Congratulations! Bo Cong On Fri, Jan 20, 2023 at 7:17 AM guo jiwei wrote: > Congratulations! Bo Cong > > Regards > Jiwei Guo (Tboy) > > On Fri, Jan 20, 2023 at 6:36 AM Neng Lu wrote: > > > > Congratulations! > > > > On Thu, Jan 19, 2023 at 7:18 AM Zike Yang wrote: > > > > > Congratulations! Bo Cong > > > > > > BR, > > > Zike Yang > > > > > > On Thu, Jan 19, 2023 at 6:11 PM Jiuming Tao > > > wrote: > > > > > > > > Congrats！ > > > > > > > > > 2023年1月18日 21:50，PengHui Li 写道： > > > > > > > > > > Hi all, > > > > > > > > > > The Apache Pulsar Project Management Committee (PMC) has invited Bo > > > Cong > > > > > (https://github.com/congbobo184) as a member of the PMC and we are > > > > > pleased to announce that he has accepted. > > > > > > > > > > He is very active in the community in the past few years and made a > > > lot of > > > > > great contributions > > > > > such as transactions and schemas. > > > > > > > > > > Welcome Bo Cong to the Apache Pulsar PMC. > > > > > > > > > > Best Regards, > > > > > Penghui on behalf of the Pulsar PMC > > > > > > > > -- Regards Nitin Goyal
Re: [DISCUSS] PIP-239: Retry Mechanism per Message
Hello all, I have a few questions. 1. When a message is NACKed does it still send the commands to the broker? 2. Do we have any plan to replace the ReconsumeLater function with NACK Backoff interface in future? On Tue, Jan 10, 2023 at 7:17 PM Nitin Goyal wrote: > 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 producing. > > There are two types of retry in current architecture which consumers can > go with. > > 1. Process later with an NACK backoff policy: In this case if someone > wants to retry and wants to set a maximum retry at message processor level. > They can get the number of times the message has been retried so far > by calling the `reconsumeTimes` function. they will match the number with > their custom retry. Now there are two things that will happen. Either they > will call ACK that particular message or they have to call the > `reconsumeLater` function based on system requirement. If they call ACK > then the message is marked as delete in the ledger. And other cases would > be explained in point 2. > > 2. By calling reconsumeLater: In some real cases if someone is calling > reconsumeLater with a delay like they want to process a message again but > after a particular time. so the new message gets created in the consumer > RETRY topic which was again processed by the consumer (they may call the > reconsumeLater again if the system requires based on use cases.). Now if > the message reaches its retry limit which was configured at consumer level > they will be sent to the DLQ message. > > So my proposal will not make any changes to 1st scenario which is to use > NACK backoff for retrying the message and process. Consumers can use the > same mechanism as they are doing now. > > It adds an additional feature to pulsar in which if a producer knows how > many times an event should be processed a max apart from the consumer max > retry and send to DLQ if reaches its limit. Then the above change will > check if the limit is reached for reconsume later then it will send to DLQ > even if the consumer has higher reconsme later retry limit. > > if producers do not pass the max retry limit it will obey the consumer > retry limit. > > Also in this PIP we are not removing the consumer own retry limit it would > be there. but get overridden by message limit if passed by the producer. if > a consumer wants to re-override that limit ( temporarily change in the > retry limit) which also can be achieved by sending a new max retry as > custom property to the `reconsumeLater` function. > > So let me rephrase the subject for this pip is to `*MAX RECONSUME TIMES > per Message*`. > > Michael's point about adding relation between producer and consumer? > > Yeah, It added a relation b/w them but it would be loose coupling. Because > producers can send the max retry limit in a message which can be overridden > by the consumer if needed. so consumers do not have to obey the limit if > needed. > > Why I prefer message properties over `MessageMetadata` is because if a > consumer wants to override the max limit (temporarily or permanent) then it > would be difficult to update if required. > > I hope the above content answers most of the doubts about this PIP. > > On Tue, Jan 10, 2023 at 5:59 PM r...@apache.org > wrote: > >> 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 scenarios, it may be a more elegant way to retry if we >> verify Nack multiple times. The current implementation of ReconsumeLater >> relies on delayed messages. This is not an elegant way, and there is no >> way >> to record the number of retries. >> >> In order to support backoff retries, we introduced the NackBackoff >> strategy, which itself is an interface and exposed to users. Based on this >> interface, we can do more customized things. If the NackBackoff interface >> can't meet our current needs, I prefer that we implement more parameters >> in >> the NackBackoff strategy instead of continuing to add new functional logic >> in ReconsumeLater. >> >> -- >> Thanks >> Xiaolong Ran >> >> Enrico Olivelli 于2023年1月10日周二 16:23写道： >> >>
Re: [VOTE] PIP-239: Retry Mechanism per Message title
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 11:35 PM, Enrico Olivelli > wrote: > > > > 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, > >>> 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 > >>>>>> > >>>>>> 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
Re: [ANNOUNCE] Yunze Xu as a new PMC member in Apache Pulsar
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 Committee (PMC) has invited Yunze > Xu > > > (https://github.com/BewareMyPower) as a member of the PMC and we are > > > pleased to announce that he has accepted. > > > > > > He is very active in the community in the past few years and made a lot > > of great contributions. > > > > > > Welcome Yunze to the Apache Pulsar PMC. > > > > > > Best Regards, > > > Haiting Jiang on behalf of the Pulsar PMC > > > > > > > >
Re: [VOTE] PIP-239: Retry Mechanism per Message title
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, delays in that. Because currently there is no PIP or discussion thread open to discuss deprecation of the reconsumeLater function in favor of NACK Backoff Interface. And my guess is that because not all the client libraries are yet supported NACKBackoff policy as of now. On Tue, Jan 10, 2023 at 8:18 PM r...@apache.org wrote: > 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 protocol. > Its state is persisted on the broker side but not on the consumer side, so > restarting the consumer will not cause the loss of the message > RedeliverCount attribute. Of course, situations such as Broker downtime and > restart are excluded. > > > 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. > > My thoughts on this point may not be consistent with yours. The logic of > Nack is to send messages to DLQ. We can configure how many Nacks will be > sent to DLQ. The request of the Redeliver Command is in the memory state of > the Consumer, but if the restart of the Consumer is considered, the Broker > will continue to push the unack message after the consumer restarts, and > will not discard this state. Whether the message will be sent to the same > consumer after Nack is the same principle as ReconsumeLater, and also > depends on what subscription type you use. It's just that because > ReconsumeLater uses the implementation logic of delayed messages, it is > only applicable to shared subscription types. > > > 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. > > Again, we expose the NackBackoff interface, this behavior can be controlled > by the user. > > In response to what you said about increasing the number of retries at the > message level or customizing the message `+1`, but here I actually want to > implement this logic in the logic of Nack instead of adding more logic to > the existing ReconsumeLater, because In subsequent version iterations, I > would like to discuss with you whether we want to discard the logic of > ReconsumeLater. > > -- > Thanks > Xiaolong Ran > > Nitin Goyal 于2023年1月10日周二 22:07写道： > > > 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 > > > 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 N
Re: [VOTE] PIP-239: Retry Mechanism per Message title
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 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 于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 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 于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 < > > 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
Re: [DISCUSS] PIP-239: Retry Mechanism per Message
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 producing. There are two types of retry in current architecture which consumers can go with. 1. Process later with an NACK backoff policy: In this case if someone wants to retry and wants to set a maximum retry at message processor level. They can get the number of times the message has been retried so far by calling the `reconsumeTimes` function. they will match the number with their custom retry. Now there are two things that will happen. Either they will call ACK that particular message or they have to call the `reconsumeLater` function based on system requirement. If they call ACK then the message is marked as delete in the ledger. And other cases would be explained in point 2. 2. By calling reconsumeLater: In some real cases if someone is calling reconsumeLater with a delay like they want to process a message again but after a particular time. so the new message gets created in the consumer RETRY topic which was again processed by the consumer (they may call the reconsumeLater again if the system requires based on use cases.). Now if the message reaches its retry limit which was configured at consumer level they will be sent to the DLQ message. So my proposal will not make any changes to 1st scenario which is to use NACK backoff for retrying the message and process. Consumers can use the same mechanism as they are doing now. It adds an additional feature to pulsar in which if a producer knows how many times an event should be processed a max apart from the consumer max retry and send to DLQ if reaches its limit. Then the above change will check if the limit is reached for reconsume later then it will send to DLQ even if the consumer has higher reconsme later retry limit. if producers do not pass the max retry limit it will obey the consumer retry limit. Also in this PIP we are not removing the consumer own retry limit it would be there. but get overridden by message limit if passed by the producer. if a consumer wants to re-override that limit ( temporarily change in the retry limit) which also can be achieved by sending a new max retry as custom property to the `reconsumeLater` function. So let me rephrase the subject for this pip is to `*MAX RECONSUME TIMES per Message*`. Michael's point about adding relation between producer and consumer? Yeah, It added a relation b/w them but it would be loose coupling. Because producers can send the max retry limit in a message which can be overridden by the consumer if needed. so consumers do not have to obey the limit if needed. Why I prefer message properties over `MessageMetadata` is because if a consumer wants to override the max limit (temporarily or permanent) then it would be difficult to update if required. I hope the above content answers most of the doubts about this PIP. On Tue, Jan 10, 2023 at 5:59 PM r...@apache.org wrote: > 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 scenarios, it may be a more elegant way to retry if we > verify Nack multiple times. The current implementation of ReconsumeLater > relies on delayed messages. This is not an elegant way, and there is no way > to record the number of retries. > > In order to support backoff retries, we introduced the NackBackoff > strategy, which itself is an interface and exposed to users. Based on this > interface, we can do more customized things. If the NackBackoff interface > can't meet our current needs, I prefer that we implement more parameters in > the NackBackoff strategy instead of continuing to add new functional logic > in ReconsumeLater. > > -- > Thanks > Xiaolong Ran > > Enrico Olivelli 于2023年1月10日周二 16:23写道： > > > 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 definition). > > > > Isn't it possible to implement what you want with an Interceptor or > > with some custom handling for the DLQ ? > > The DLQ (currently) in Pulsar is mostly a client-side feature. > > The producer can tag the messages with a message property and the > > client can decide what to do > > and ho
Re: [DISCUSS] PIP-239: Retry Mechanism per Message
Hello Enrico, For your concern about temporarily increasing of retry. It can be achieved using overriding msg property while calling reconsuming later with custom properties.. About msg immutable as per current design if consumer call reconsumeLater function it creates a new msg in the system adding few properties to it like how many times it get consumed. That also allow other custom properties to be added in newly generated msg.. so if msg needs temporary high retry or change in retry count on msg they can override it using custom properties… Thanks Nitin Goyal On Mon, 9 Jan 2023 at 1:11 PM, Enrico Olivelli wrote: > I don't think that this is a good idea. > > Because IIUC we want to add a property per message that sets the > maximum time of retries. > > Unfortunately in a real system sometimes you have to change the number > of retries temporarily, > for instance in case of major system failure you don't want to lose > all your messages. > > If we allow you to set a property on a message then you won't be able > to change it because the message is immutable. > > TTL (time to live) is a similar concept but it is related to the > concept of "physical time", if you have message that represents > a task to be executed within a given deadline then it makes sense to > state it in the message metadata. > > But the "number of retries" depends on how you deal with the retries: > - how much time do you wait ? > - how often do you have a temporary failure to retry ? > > It would make more sense to have a QOS (quality of service) attribute > on the message, like "important/"non-important"/"foo"/"bar" > and have a way for the brokers and the clients to handle that. I am > pretty sure that with interceptors you can already do something. > > > I am against hard coding the behaviour described in the PIP (and I > voted -1 in the VOTE thread) > > Enrico > > Il giorno ven 6 gen 2023 alle ore 09:11 Zike Yang ha > scritto: > > > > Hi, > > > > This looks good to me. > > +1 > > > > I was thinking if we could add a new API for `reconsumeLater` to let > > users set the max retry times easily. But I saw that there are too > > many reconsumeLater API and this will make the consumer more complex. > > > > Thanks, > > Zike Yang > > > > > > On Thu, Jan 5, 2023 at 3:58 PM Zixuan Liu wrote: > > > > > > +1 > > > > > > Thanks, > > > Zixuan > > > > > > Nitin Goyal 于2023年1月5日周四 13:50写道： > > > > > > > Hi all, > > > > > > > > I made a PIP to discuss: > https://github.com/apache/pulsar/issues/19136 > > > > > > > > Thanks, > > > > Nitin Goyal > > > > > -- Regards Nitin Goyal
[VOTE] PIP-239: Retry Mechanism per Message title
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
[DISCUSS] Retry logic per message
Hello all, We can add an retry logic per message. This feature can allow developers to add custom retries per message and defaults to consumer retries. Currently all client libs are taking care of when to send a message to Retry or DLQ topic based on redelivery times defined while creating consumers. Proposed PR for go client library: https://github.com/apache/pulsar-client-go/pull/939 The same can be done for other client libraries. -- Regards Nitin Goyal
[DISCUSS] PIP-239: Retry Mechanism per Message
Hi all, I made a PIP to discuss: https://github.com/apache/pulsar/issues/19136 Thanks, Nitin Goyal
Re: [DISCUSS] Retry logic per message
I have created a PIP for the same please find the url below for it. https://github.com/apache/pulsar/issues/19136 On Thu, Jan 5, 2023 at 8:20 AM Haiting Jiang wrote: > The motivation looks good. > > But I think we should go through a PIP process to get it approved. > So that other languages can get track of this new feature, > especially it use a new system property to implement this feature. > > > Haiting > > On Wed, Jan 4, 2023 at 6:09 PM Zixuan Liu wrote: > > > > Hi Nitin, > > > > This discussion looks good to me. > > > > Thanks, > > Zixuan > > > > Nitin Goyal 于2023年1月4日周三 17:53写道： > > > > > Hello all, > > > > > > We can add an retry logic per message. This feature can allow > developers to > > > add custom retries per message and defaults to consumer retries. > > > > > > Currently all client libs are taking care of when to send a message to > > > Retry or DLQ topic based on redelivery times defined while creating > > > consumers. > > > > > > Proposed PR for go client library: > > > https://github.com/apache/pulsar-client-go/pull/939 > > > > > > The same can be done for other client libraries. > > > -- > > > Regards > > > Nitin Goyal > > > > -- Regards Nitin Goyal
[DISCUSS] Retry logic per message
Hello all, We can add an retry logic per message. This feature can allow developers to add custom retries per message and defaults to consumer retries. Currently all client libs are taking care of when to send a message to Retry or DLQ topic based on redelivery times defined while creating consumers. Proposed PR for go client library: https://github.com/apache/pulsar-client-go/pull/939 The same can be done for other client libraries. -- Regards Nitin Goyal
