[VOTE] PIP-99 Pulsar Proxy Extensions

[Enrico Olivelli]

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 PIP is approved)
https://github.com/apache/pulsar/pull/11838

Please VOTE within 72 hours, approximately Thursday 30th

Best regards
Enrico

Re: [VOTE] PIP-99 Pulsar Proxy Extensions

[Matteo Merli]

+1


--
Matteo Merli


On Mon, Sep 27, 2021 at 3:01 AM 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 PIP is approved)
> https://github.com/apache/pulsar/pull/11838
>
> Please VOTE within 72 hours, approximately Thursday 30th
>
> Best regards
> Enrico

Re: [VOTE] PIP-99 Pulsar Proxy Extensions

[Lari Hotari]

+1, non binding

ma 27. syysk. 2021 klo 12.01 Enrico Olivelli 
kirjoitti:

> 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 PIP is approved)
> https://github.com/apache/pulsar/pull/11838
>
> Please VOTE within 72 hours, approximately Thursday 30th
>
> Best regards
> Enrico
>

Re: [VOTE] PIP-99 Pulsar Proxy Extensions

[Michael Marshall]

+1 (non-binding)

Thanks,
Michael

On Mon, Sep 27, 2021 at 12:46 PM Lari Hotari  wrote:
>
> +1, non binding
>
> ma 27. syysk. 2021 klo 12.01 Enrico Olivelli 
> kirjoitti:
>
> > 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 PIP is approved)
> > https://github.com/apache/pulsar/pull/11838
> >
> > Please VOTE within 72 hours, approximately Thursday 30th
> >
> > Best regards
> > Enrico
> >

Re: [VOTE] PIP-99 Pulsar Proxy Extensions

[Christophe Bornet]

+1

Le lun. 27 sept. 2021 à 11:01, Enrico Olivelli  a
écrit :

> 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 PIP is approved)
> https://github.com/apache/pulsar/pull/11838
>
> Please VOTE within 72 hours, approximately Thursday 30th
>
> Best regards
> Enrico
>

[VOTE] PIP-97 Asynchronous Authentication Provider

[Michael Marshall]

Hi Pulsar Community,

I would like to start a VOTE for PIP-97 Asynchronous Authentication Provider.

The issue for this PIP is here:
https://github.com/apache/pulsar/issues/12105.

The PR for all interface changes this PIP requires are here:
https://github.com/apache/pulsar/pull/12104. Note that I deprecate
several authentication methods that this PIP renders unnecessary.

Please VOTE within 72 hours.

Thanks,
Michael

Re: [Proposal] Make Dispatcher pluggable

[PengHui Li]

Thanks, LGTM.

Penghui

On Sun, Sep 26, 2021 at 4:32 PM Lin Lin  wrote:

>
>
> On 2021/09/24 14:09:14, PengHui Li  wrote:
> > Sorry for the late reply,
> >
> > If a batch has 10 messages, but users only want to filter out parts of
> them
> > such as 3 messages, only 7 messages should be processed at the consumer
> > side.
> > So if the proposal is for the entry filter, I think we should have the
> > EntryFitler interface, not MessageFilter?
> >
> > Actually, I also have some doubts about the entry filter, not sure if it
> > can be used in the real world. Or we should disable the batch when using
> > the filter or deserialize
> > the single message metadata to decide if the consumer should skip this
> > message, looks both of them will bring greater overhead to the broker.
> >
> > But I am not against the pluggable filter, not all users consider the
> > performance first, If they are more think about it at a functional
> > perspective, the pluggable filter will help them.
> > We should clarify it in the proposal, let users know how to make
> trade-offs.
> >
> > Thanks,
> > Penghui
> >
>
>
> Hello penghui,
> I agree with your concerns. At this stage, we can only do Entry-level
> filtering. If the Message in the Entry is forced to be filtered on the
> Broker side, there will be problems in the subsequent consumer ack.
> Therefore, if we want to use this filter, we must set
> enableBatching=false, which is the same as delayed messages.
>
> I will explain this point in the comments of the interface
>
> Thanks,
> Lin Lin
>

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

[PengHui Li]

+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写道：
>
> > Dear Pulsar community, please vote now on PIP 95:
> > https://github.com/apache/pulsar/issues/12040
> >
> > Note that there are numerous proposals that have been labeled as PIP 95.
> > Sorry for the inconvenience.
> >
> > --
> > Eron Wright
> > StreamNative
> >
>

Re: [VOTE] PIP-99 Pulsar Proxy Extensions

[PengHui Li]

+1

Penghui

On Tue, Sep 28, 2021 at 3:22 AM Christophe Bornet 
wrote:

> +1
>
> Le lun. 27 sept. 2021 à 11:01, Enrico Olivelli  a
> écrit :
>
> > 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 PIP is approved)
> > https://github.com/apache/pulsar/pull/11838
> >
> > Please VOTE within 72 hours, approximately Thursday 30th
> >
> > Best regards
> > Enrico
> >
>

Correct semantics of producer close

[Yunze Xu]

Hi all,

Recently I found a PR (https://github.com/apache/pulsar/pull/12195 
) that
modifies the existing semantics of producer close. There're already some
communications in this PR, but I think it's better to start a discussion here
to let more know.

The existing implementation of producer close is:
1. Cancel all timers, including send and batch container 
(`batchMessageContainer`).
2. Complete all pending messages (`pendingMessages`) with 
`AlreadyCloseException`.

See `ProducerImpl#closeAsync` for details.

But the JavaDoc of `Producer#closeAsync` is:

> No more writes will be accepted from this producer. Waits until all pending 
> write request are persisted.

Anyway, the document and implementation are inconsistent. But specifically,
we need to define the behavior for how to process `pendingMessages` and
`batchMessageContainer` when producer call `closeAsync`.

1. batchMessageContainer: contains the buffered single messages (`Message`). 
2. pendingMessages: all inflight messages (`OpSendMsg`) in network.

IMO, from the JavaDoc, only `pendingMessages` should be processed and the
messages in `batchMessageContainer` should be discarded.

Since other clients might have already implemented the similar semantics of
Java clients. If we changed the semantics now, the behaviors among different
clients might be inconsistent.

Should we add a configuration to support graceful close to follow the docs? Or
just change the current behavior?

Thanks,
Yunze