[GitHub] [pulsar-site] Jason918 opened a new pull request, #199: Update Python Client docs for 2.7.5
Jason918 opened a new pull request, #199: URL: https://github.com/apache/pulsar-site/pull/199 Update Python Client docs for 2.7.5 Note: Command `PULSAR_VERSION=2.7.5 ./site2/tools/api/python/build-docs-in-docker.sh` fails when install `grpcio` in pip, with following error stack. ``` Traceback (most recent call last): File "", line 2, in File "", line 34, in File "/tmp/pip-install-qvll8fsg/grpcio_385d075b3dc3471d8dcb18eb91277b76/setup.py", line 263, in if check_linker_need_libatomic(): File "/tmp/pip-install-qvll8fsg/grpcio_385d075b3dc3471d8dcb18eb91277b76/setup.py", line 219, in check_linker_need_libatomic cpp_test = subprocess.Popen( File "/opt/python/cp38-cp38/lib/python3.8/subprocess.py", line 854, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "/opt/python/cp38-cp38/lib/python3.8/subprocess.py", line 1627, in _execute_child executable = os.fsencode(executable) File "/opt/python/cp38-cp38/lib/python3.8/os.py", line 806, in fsencode filename = fspath(filename) # Does type-checking of `filename`. TypeError: expected str, bytes or os.PathLike object, not list ``` So this PR doc is auto-generated with docker image `apachepulsar/pulsar-build:ubuntu-20.04` and manually installed python 3.8. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [DISCUSS] User-friendly acknowledgeCumulative API on a partitioned topic or multi-topics
What eventually happened with this idea? On Fri, Jul 29, 2022 at 8:02 AM PengHui Li wrote: > +1 > > Penghui > On Jul 28, 2022, 20:14 +0800, lordcheng10 <1572139...@qq.com.invalid>, > wrote: > > Nice feature! > > > > > > > > > > -- Original -- > > From: "Yunze Xu" > Date: 2022Äê7ÔÂ15ÈÕ(ÐÇÆÚÎå) ÍíÉÏ6:04 > > To: "dev" > 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 > 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 > ``` > > > > 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 >
Re: [DISCUSS] User-friendly acknowledgeCumulative API on a partitioned topic or multi-topics
I am busy on other things recently so there is no further update. But I found there is already two methods to acknowledge multiple messages in Java client. ```java void acknowledge(Messages messages) throws PulsarClientException; void acknowledge(List messageIdList) throws PulsarClientException; ``` And here is the issue to track the catch up: https://github.com/apache/pulsar/issues/17428 Yunze > On Sep 4, 2022, at 22:37, Asaf Mesika wrote: > > What eventually happened with this idea? > > On Fri, Jul 29, 2022 at 8:02 AM PengHui Li wrote: > >> +1 >> >> Penghui >> On Jul 28, 2022, 20:14 +0800, lordcheng10 <1572139...@qq.com.invalid>, >> wrote: >>> Nice feature! >>> >>> >>> >>> >>> -- Original -- >>> From: "Yunze Xu">> Date: 2022Äê7ÔÂ15ÈÕ(ÐÇÆÚÎå) ÍíÉÏ6:04 >>> To: "dev">> 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>> 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>> ``` >>> >>> 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 >>
[GitHub] [pulsar-site] urfreespace merged pull request #197: Set notifications and merge buttons
urfreespace merged PR #197: URL: https://github.com/apache/pulsar-site/pull/197 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [VOTE] [PIP-204] Extensions for BrokerInterceptor
Hi, Thanks all for voting. The voting is now closed and passed with 3 binding +1, 5 non-binding +1, and no 0 or -1 votes. +1 bindings: Enrico Olivelli Jiwei Guo Penghui Li +1 non-bindings: Lin Chen Haiting Jiang tison Max Xu Anon Hxy Best, Aloys Anon Hxy 于2022年9月2日周五 14:04写道： > +1 (non-binding) > > Thanks, > Xiaoyu Hou > > Aloys Zhang 于2022年8月30日周二 19:02写道： > > > Hi devs, > > > > This is the VOTE thread for PIP-204 Extensions for BrokerInterceptor. > > > > PIP issue: https://github.com/apache/pulsar/issues/17267 > > > > Discussion thread: > > https://lists.apache.org/thread/3zgpbxffo7gzsb5mdh0sk2rq27bgw2bo > > > > This voting will open for at least 72h. > > > > > > > > Best, > > Aloys > > >
