[RESULT] [VOTE] PIP-99 Pulsar Proxy Extensions

Hello, we can close the VOTE now and mark PIP-99 as Approved. I will copy the text from the issue to the Wiki Let's follow up on the PR for the implementation. We have 9 +1 (5 binding, 4 non binding): Matteo, Enrico, Penghui, Lin Lin, Hang Chen, Christophe, Micheal, Lari, Yunze Thank you for t

[GitHub] [pulsar-dotpulsar] blankensteiner commented on issue #84: Recover after network disconnect

blankensteiner commented on issue #84: URL: https://github.com/apache/pulsar-dotpulsar/issues/84#issuecomment-930828254 Hi @dunkymole The PR doesn't seem finished (open questions and writing to the console in the code) and I think it is better solved using ping/pong. Right now DotPulsar

Re: Separate topic and partition label for Prometheus metrics in 2.9.0

Penghui, Il Gio 30 Set 2021, 06:10 PengHui Li ha scritto: > Hi all, > > Hope you are well, currently, we are exposing the topic metrics with an > open one label topic which > is the complete topic name such as > `persistent://public/default/xxx-partition-0`, but as > https://github.com/apache/pu

Re: [VOTE] PIP-96 Message payload processor for Pulsar client

+1 (binding) Enrico Il Gio 30 Set 2021, 06:08 Yunze Xu ha scritto: > Hi folks, > > It has been about two weeks since I opened the PIP-96 issue and the design > has > changed a lot. Thanks a lot for @eolivelli's suggestions. I think now it's > time > to start a vote. > > PIP-96 issue: https://g

Separate topic and partition label for Prometheus metrics in 2.9.0

Hi all, Hope you are well, currently, we are exposing the topic metrics with an open one label topic which is the complete topic name such as `persistent://public/default/xxx-partition-0`, but as https://github.com/apache/pulsar/issues/11432 mentioned, we are not able to have an aggregated metrics

[VOTE] PIP-96 Message payload processor for Pulsar client

Hi folks, It has been about two weeks since I opened the PIP-96 issue and the design has changed a lot. Thanks a lot for @eolivelli's suggestions. I think now it's time to start a vote. PIP-96 issue: https://github.com/apache/pulsar/issues/12087 T

[GitHub] [pulsar-dotpulsar] dunkymole commented on issue #84: Recover after network disconnect

dunkymole commented on issue #84: URL: https://github.com/apache/pulsar-dotpulsar/issues/84#issuecomment-930278162 Hey, My team has also seen issues whereby the client gets zombied, presumably also after some sort of network blip. I can well understand how @PetterIsberg's repro woul

[GitHub] [pulsar-dotpulsar] dunkymole commented on issue #84: Recover after network disconnect

dunkymole commented on issue #84: URL: https://github.com/apache/pulsar-dotpulsar/issues/84#issuecomment-930278162 Hey, My team has also seen issues whereby the client gets zombied, presumably also after some sort of network blip. I can well understand how @PetterIsberg's repro woul

Re: [VOTE] [PIP 95] Smart Listener Selection with Multiple Bind Addresses

Seems we have a consensus to accept, thanks everyone. On Mon, Sep 27, 2021 at 6:10 PM PengHui Li wrote: > +1 (binding) > > Penghui > > On Sun, Sep 26, 2021 at 10:19 AM Fangbin Sun wrote: > > > +1(non-binding) > > > > Thanks, > > Fangbin > > > > Eron Wright 于2021年9月25日周六 上午3:41写道： > > > > > Dea

Re: Correct semantics of producer close

I agree that we must ensure that every pending callback must be completed eventually (timeout or another error is not a problem), because we cannot let the client application hang forever. I believe that the application can perform a flush() explicitly and also wait for every callback to be execute

?????? Correct semantics of producer close

I agree to try to ensure ??at most once?? when closing?? > That would still get controlled by send timeout, after that, the send will fail and close should proceed. This sounds more in line with ??at most once --  -- ??:

Re: [VOTE] PIP-99 Pulsar Proxy Extensions

+1 Thanks, Hang Lin Lin 于2021年9月29日周三 下午3:57写道： > > > > On 2021/09/27 09:00:52, Enrico Olivelli wrote: > > Hello everyone, > > > > I would like to start a VOTE for PIP-99 Pulsar Proxy Extensions > > > > This is the PIP-99 > > https://github.com/apache/pulsar/issues/12157 > > > > This is the PR

Re: [VOTE] PIP-99 Pulsar Proxy Extensions

On 2021/09/27 09:00:52, Enrico Olivelli wrote: > Hello everyone, > > I would like to start a VOTE for PIP-99 Pulsar Proxy Extensions > > This is the PIP-99 > https://github.com/apache/pulsar/issues/12157 > > This is the PR for the implementation (still draft, I will complete it > after the

Re: Correct semantics of producer close

> but equally they might be > surprised when closeAsync doesn't complete because the pending messages > can't be cleared That would still get controlled by send timeout, after that, the send will fail and close should proceed. -- Matteo Merli On Wed, Sep 29, 2021 at 12:52 AM Jack Vanlightly wr

Re: Correct semantics of producer close

I can see both sides of the argument regarding whether to flush pending messages or not. But I think what is definitely in the contract is not to discard any callbacks causing user code to block forever. No matter what, we must always call the callbacks. Personally, I am in favour of a close opera