Re: Correct semantics of producer close

>I don't think that implementing `closeAsync` with graceful shutdown logic implies a guarantee of message publishing. Rather, it guarantees that failures will be the result of a real exception or a timeout. I think that's beside the point. There is no definition of "real" exceptions. At that

[PIP] Add seek by index feature for consumer

Hi Pulsar Community, I would like to propose a new feature for consumer, seek by index. Currently we can reset the read position of a cursor by message id or timestamp. Since we formerly introduced index in broker metadata since 2.8.0, reset cursor by index is very useful in some use cases. eg

Re: [PIP 100] Add seekByIndex for consumer api

Hi Yunze, Thanks for the reminding.  I will come up with the issue and new mail for this pip. -- Original -- From: "dev"

Re: [PROPOSAL] Support level increment delay for ReconsumerLater interface

> 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

Re: [PROPOSAL] Support level increment delay for ReconsumerLater interface

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

Re: [PROPOSAL] Support level increment delay for ReconsumerLater interface

> 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

Re: Correct semantics of producer close

It’s a good point that `ProducerImpl#failPendingBatchMessages` treats messages in batch container also as pending messages. I agree with your definition of "graceful close”. It’s more like a “at most once” semantics, like the original JavaDoc said > pending writes will not be retried Thanks, Yu

Re: Problems with PIP ID Management

Thanks for your feedback Enrico. I'd appreciate any other thoughts on this process since I am proposing a change to a recently implemented PIP. Also, if we like this new direction, I think we should update our GitHub issue template to communicate this new process. I already have a PR for my propo

Re: Correct semantics of producer close

Thanks for bringing this thread to the mailing list, Yunze. I think the right change is to update the `closeAsync` method to first flush `batchMessageContainer` and to then asynchronously wait for the `pendingMessages` queue to drain. We could add a new timeout or rely on the already implemented `

PIP-100: Pulsar pluggable topic factory

Hi, I would like to propose a Pluggable topic factory in pulsar. Users select the topic type (persistent/non-persistent) based on the application use case and requirement of topic behavior. However, in some circumstances, users need some additional behavior on top of the existing implementation an

[GitHub] [pulsar-client-node] massakam commented on issue #122: npm install fails on win10

massakam commented on issue #122: URL: https://github.com/apache/pulsar-client-node/issues/122#issuecomment-929050029 > IMHO, the solution is to have this project publish the c++ binaries. You can see from the following output that npm/node-gyp is trying to fetch the prebuilt. Unfo

Re: [PROPOSAL] Support level increment delay for ReconsumerLater interface

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

Re: [PIP 100] Add seekByIndex for consumer api

I have edited the Wiki page for PIP https://github.com/apache/pulsar/wiki/Pulsar-Improvement-Proposal-(PIP) Thanks, Yunze

Re: [PIP 100] Add seekByIndex for consumer api

You need to create an issue first to start a discussion for your PIP. Here’s the process of PIP: 1. The author(s) of the proposal will create a GitHub issue ticket choosing the template for PIP proposals. 2. The author(s) will send a note to the dev@pulsar.apache.org

[PIP 100] Add seekByIndex for consumer api

Hi Pulsar Community, I'm glad to have this opportunity to propose this PIP. Currently we can reset the read position of a cursor by message id or timestamp.  Since we formerly introduced index in broker metadata since 2.9.0,  reset cursor by index is very helpful in other protocol handler (KoP

Re: [VOTE] PIP-99 Pulsar Proxy Extensions

+1 (non binding) Thanks, Yunze

Re: Adding a new token and GH secret for the doc bot

I have created a INFRA ticket https://issues.apache.org/jira/browse/INFRA-22368 I will provide a personal token If anyone has a better idea please chime in Any help is really appreciated Enrico Il giorno gio 23 set 2021 alle ore 08:59 Enrico Olivelli < eolive...@gmail.com> ha scritto: > Hello

[GitHub] [pulsar-client-node] massakam commented on issue #122: npm install fails on win10

massakam commented on issue #122: URL: https://github.com/apache/pulsar-client-node/issues/122#issuecomment-929050029 > IMHO, the solution is to have this project publish the c++ binaries. You can see from the following output that npm/node-gyp is trying to fetch the prebuilt. Unfo

Re: Correct semantics of producer close

I can’t agree more, just like what I’ve said in PR 12195: > At any case, when you choose `sendAsync`, you should always make use of the > returned future to confirm the result of all messages. In Kafka, it's the > send callback. But I found many users are confused about the current behavior, es

Re: Correct semantics of producer close

Clients should not depend on any of this behaviour, since the broker is at the other end of an unreliable network connection. The semantic differences are kind of meaningless from a usability point, since flushing on close =/= published. What exactly does "graceful" convey here? Flush the buffe

Re: [PROPOSAL] Support level increment delay for ReconsumerLater interface

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