Regarding your question "why AUTO_ACK is designed this way"
I think at the time when it's firstly implemented, the AUTO_ACK is just a
convenient way to help user ack the message.
We can discuss the gap between expected behavior and actual behavior and try to
resolve or simplify it.
On
> For users, sink is also part of the function framework.
^^ Is this written inside any Pulsar documentation? If you look the code
closely, the source and sink are actually configurable in Java runtime. User
can actually provide their own source/sink implementation.
On 2022/05/10 01:38:48
> AUTO_ACK setting means if the function runtime will ack messages or not.
> ("function runtime" here specifically refers to the JavaInstanceRunnable. If
> the ack happens inside a sink's implemented write method, it's not auto-ack).
The description of the official website document is：Whether
Thanks reply,
> If AUTO_ACK is TRUE, then the JavaInstanceRunnable will be acking messages.
> If AUTO_ACK is FALSE, then the acking will be done by Sink implementation.
A little confused, I want to know why AUTO_ACK is designed this way.
I'll give another example:
> If AUTO_ACK is TRUE, then
Thanks for this detailed discussion about processing guarantee and ack.
These two settings are together affecting the behavior of a running function.
One thing I want to clarify is:
AUTO_ACK setting means if the function runtime will ack messages or not.
("function runtime" here specifically
