> 1. The new API looks very similar to the existing delay-queue based
> implementation but It's very different in nature, which might confuse
users.
Hello PenghuiLi:
In response to this problem, I am also a bit confused. The current
implementation of ReconsumerLater is also the solution of calling
DelayMessage. This PIP is an enhancement of the current ReconsumerLater, so
the implementation here is whether we continue to use DelayMessage or we
Repackage Time Tracker by yourself, stripping a clean API interface.
--
Thanks
Xiaolong Ran
PengHui Li <peng...@apache.org> 于2021年9月28日周二 下午4:02写道：
> Hi Xiaolong,
>
> Currently, in the Pulsar client, we have ack timeout, negative ack, and
> reconsume later method to achieve diverse message redelivery requirements.
> I agree with the client side flexible message redelivery controlling but I
> have a few concerns with the new API.
>
> 1. The new API looks very similar to the existing delay-queue based
> implementation but It's very different in nature, which might confuse
> users.
> 2. Does the redelivery level can be specified by users? In my opinion, we
> can provide a default exponentially backed off policy for users and we'd
> better support customize it.
> 3. I think if make some enhancements for the ack timeout is more
> reasonable, the ack timeout handling will not use the delay queue such as
> we have an AckTimePolicy there
> And by default, we can support an ExponentiallyBackoffAckTimePolicy,
> and XXXAckTimeoutPolicy and YYYAckTimeoutPolicy can be implemented by
> users.
>
> Thanks,
> Penghui.
>
> On Fri, Sep 10, 2021 at 4:33 PM r...@apache.org <ranxiaolong...@gmail.com>
> wrote:
>
> > Hello everyone:
> >
> > I wrote a proposal to enhance the functionality of ReconsumeLater, the
> > specific content is as follows:
> >
> > ---
> >
> > # PIP 94: Support level increment delay for ReconsumerLater interface
> >
> > - Status: Draft
> > - Author: Xiaolong Ran
> > - Pull request:
> > - Mailing list discussion:
> > - Release:
> >
> > The purpose of this proposal is mainly to add ReconsumerLater on the
> > consumer side to retry in an incremental level
> >
> > ## Motivation
> >
> > At present, ReconsumrLater only supports specifying a specific delay time
> > for distribution processing. The usage is as follows:
> >
> > ```
> > while (true) {
> > Message<String> msg = consumer.receive();
> >
> > try {
> > // Process message...
> >
> > consumer.acknowledge(msg);
> > } catch (Throwable t) {
> > log.warn("Failed to process message");
> > consumer.reconsumeLater(msg, 1000 , TimeUnit.MILLISECONDS);
> > }
> > }
> > ```
> >
> > Its implementation principle is to use Pulsar's built-in delay message to
> > pass in the specified time as the parameter
> > of deliverAfter(), and then push the message to the consumer side again
> > after the time arrives.
> >
> > This is a good idea, which allows users to flexibly define their own
> delay
> > time in a specific scenario. But assuming
> > that the message is not processed correctly within the time specified by
> > the user, the behavior of ReconsumerLater has
> > ended at this time. Whether we can consider adding a retry scheme
> according
> > to the time level. Then when the first
> > specified time range is not processed correctly, ReconsumerLater() can
> > automatically retry according to the time level
> > until the user correctly processes the specific message.
> >
> > ## Implementation
> >
> > As mentioned above, if we can here follow a certain delay level from low
> to
> > high and allow it to automatically retry,
> > it is a more user-friendly way. For example, we can define the following
> > delay level:
> >
> > ```
> > MESSAGE_DELAYLEVEL = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m
> 30m
> > 1h 2h"
> > ```
> >
> >
> > In this PIP, we mainly introduce two new API interfaces to users:
> >
> > 1. Specify the delay level
> >
> > ```
> > reconsumeLater(Message<?> message, int delayLevel)
> > ```
> >
> > This implementation method is consistent with the current reconsumeLater
> > interface, but instead of specifying the
> > delay level, specify the specific delay time. For example, level `1`
> > corresponds to `1s`, and level `3` corresponds to `10s`.
> >
> >
> > 2. Retry with increasing level
> >
> > ```
> > reconsumeLater(Message<?> message)
> > ```
> >
> > Different from the above two, it is a back-off retry, that is, the retry
> > interval after the first failure is 1 second,
> > and the retry interval after the second failure is 5 seconds, and so on,
> > the more the number of times, the longer the
> > interval.
> >
> > This kind of retry mechanism often has more practical applications in
> > business scenarios. If the consumption fails,
> > the general service will not be restored immediately. It is more
> reasonable
> > to use this gradual retry method.
> >
> >
> > ## Compatibility
> >
> > The current proposal will not cause damage to compatibility. It exposes
> two
> > new API interfaces based on the
> > original API for users to use, so there will be no compatibility-related
> > issues here.
> >
> > --
> > Thanks
> > Xiaolong Ran
> >
>
