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 <z...@apache.org> 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 <node...@gmail.com> wrote: > > > > +1 > > > > Thanks, > > Zixuan > > > > Nitin Goyal <nitin.goyal....@gmail.com> 于2023年1月5日周四 13:50写道： > > > > > Hi all, > > > > > > I made a PIP to discuss: https://github.com/apache/pulsar/issues/19136 > > > > > > Thanks, > > > Nitin Goyal > > >
