Thanks Penghui and Chris for the feedback.
At present, the introduction of the ReconsumerLater interface itself is
rather confusing, so we may abandon the ReconsumeLater-related interface in
later version iterations. But the backoff and retry function for messages
is indeed a scenario that users n
> 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 callin
Thanks Chris:
> It seems like an application can already do something like this without
any
> changes to the clients?
Now we can't implement such logic. Although we now provide the interface of
reconsumerLater, the real situation is that if there are some problems in
the system, it may be difficu
> 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
Thanks PenghuiLi,
Acktimeout has its own problems, such as how long should we set a
reasonable time. So in the Go SDK, we abandone
It seems like an application can already do something like this without any
changes to the clients?
An application could read the message properties and then figure out the
next time interval it should use the for the ReconsumeLater method. The
leveling concept could be a small piece of code the a
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 ver
