+1

Penghui
On Jul 28, 2022, 20:14 +0800, lordcheng10 <1572139...@qq.com.invalid>, wrote:
> Nice feature!
>
>
>
>
> ------------------&nbsp;Original&nbsp;------------------
> From: "Yunze Xu"<y...@streamnative.io.INVALID&gt;;
> Date: 2022Äê7ÔÂ15ÈÕ(ÐÇÆÚÎå) ÍíÉÏ6:04
> To: "dev"<dev@pulsar.apache.org&gt;;
> Subject: [DISCUSS] User-friendly acknowledgeCumulative API on a partitioned 
> topic or multi-topics
>
>
>
> Hi all,
>
> Long days ago I opened a PR to support cumulative acknowledgement
> for C++ client, but it's controversial about whether should a
> partitioned consumer acknowledge a message ID cumulatively.
>
> See https://github.com/apache/pulsar/pull/6796 for discussion.
>
> Currently, the Java client acknowledges the specific partition of the
> message ID, while the C++ client just fails when calling
> `acknowledgeCumulative` on a partitioned topic. However, even if the
> Java client doesn't fail, it's not user friendly.
>
> Assuming users called `acknowledgeCumulative` periodically, there is a
> chance that some messages of the specific partition has never been
> passed to the method.
>
> For example, a consumer received:
>
> P0-M0, P1-M0, P0-M1, P1-M1, P0-M2, P1-M2...
>
> And the user acknowledged every two messages, i.e.
>
> P0-M0, P0-M1, P0-M2
>
> Eventually, partition 1 has never been acknowledged.
>
> User must maintain its own `Map<String, MessageId&gt;` cache for a
> partitioned topic or multi-topics consumer with the existing
> `acknowledgeCumulative` API.
>
> Should we make it more friendly for users? For example, we can make
> `acknowledgeCumulative` accept the map to remind users to maintain
> the map from topic name to message ID:
>
> ```java
> // the key is the partitioned topic name like my-topic-partition-0
> void acknowledgeCumulative(Map<String, MessageId&gt; topicToMessageId);
> ```
>
> For those who don't want to maintain the map by themselves, maybe we
> can provide a simpler API like:
>
> ```java
> // acknowlegde all latest received messages
> void acknowledgeCumulative();
> ```
>
> and provide an option to enable this behavior.
>
> Do you have any suggestion on this idea? I will prepare a proposal if
> there is no disagreement.
>
> Thanks,
> Yunze

Reply via email to