Re: [DISCUSS] PIP-275: Introduce numWorkerThreadsForPersistentTopic to deprecate numWorkerThreadsForNonPersistentTopic in configuration

[houxiaoyu]

Hi Rajan,
Thanks for your reply.

The `numWorkerThreadsForNonPersistentTopic` will specify the thread num of
`BrokerService#topicOrderedExecutor` [0].
However, the `topicOrderedExecutor` are both used for `persistent` and
`non-persistent` topics, not just for `non-persistent`:
* There is only one place invoke `topicOrderedExecutor` for
`non-persistent` topics. [1]
* Other places will invoke `topicOrderedExecutor` for `persistent` topic,
e.g., [2][3][4][5]

In short, `numWorkerThreadsForNonPersistentTopic` is not the `Number of
worker threads to serve non-persistent topic` only.  So how about change
the name to `numWorkerThreadsTopic`


[0]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/BrokerService.java#L317C14-L320
[1]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/ServerCnx.java#L1705-L1709
[2]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherMultipleConsumers.java#L134-L142
[3]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentTopic.java#L279-L281
[4]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherSingleActiveConsumer.java#L77-L83
[5]
https://github.com/apache/pulsar/blob/50b9a93e42e412d9f17b1637287d1a4c7c7ab148/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentStickyKeyDispatcherMultipleConsumers.java#L392-L396

Thanks




Rajan Dhabalia  于2023年6月6日周二 14:57写道：

> Hi,
>
> We already have a default number of threads for persistent topics but we
> have added a feature non-persistent topics and to isolate that path we
> introduced a number of worker threads which we can reduce or tune based on
> resources we would like to allocate for non-persistent topics. So, it
> really doesn't make sense and I don't see any clear reason in this PIP why
> we would like to take away control to tune thread resources to
> non-persistent topics.
>
> Thanks,
> Rajan
>
> On Mon, Jun 5, 2023 at 10:56 PM houxiaoyu  wrote:
>
> > Hi Pulsar Community,
> >
> > I am writing to start the discussion on PIP-275: Introduce
> > numWorkerThreadsForPersistentTopic to deprecate
> > numWorkerThreadsForNonPersistentTopic in configuration
> >
> > PR with PIP contents: https://github.com/apache/pulsar/pull/20507
> >
> > # Motivation
> >
> > Introduce `numWorkerThreadsForPersistentTopic` to deprecate
> > `numWorkerThreadsForNonPersistentTopic`.
> >
> > The `numWorkerThreadsForNonPersistentTopic` is used to specify for
> > PersistentTopic, not NonPersistentTopic. So I propose change the config
> > item from `numWorkerThreadsForNonPersistentTopic` to
> > `numWorkerThreadsForPersistentTopic`:
> >
> > Thanks,
> > Xiaoyu Hou
> >
>

[ANNOUNCE] Apache Pulsar Client Python 3.2.0 released

[Yunze Xu]

The Apache Pulsar team is proud to announce Apache Pulsar Client
Python version 3.2.0.

Pulsar is a highly scalable, low latency messaging platform running on
commodity hardware. It provides simple pub-sub semantics over topics,
guaranteed at-least-once delivery of messages, automatic cursor management for
subscribers, and cross-datacenter replication.

You can download the source code and the Python wheels in:
https://archive.apache.org/dist/pulsar/pulsar-client-python-3.2.0/

The Python wheels were uploaded to PyPI as well so that they can be
installed by `pip install pulsar-client==3.2.0`.

Release Notes are at:
https://pulsar.apache.org/release-notes/versioned/client-python-3.2.0/

We would like to thank the contributors that made the release possible.

Regards,

The Pulsar Team

Re: [VOTE] PIP-272

[Asaf Mesika]

I'm sorry for not getting back to you sooner: Weekend, work, etc.

I vote -1 (non-binding), as I found something rather disturbing in the
design.

Can we please go back to the discussion (in the PR)?

Rui Fu - I see you voted +1 (binding) - what do you think about the
comments I've made?

Thanks!


On Tue, Jun 6, 2023 at 8:07 AM Rui Fu  wrote:

> +1
>
> Best,
>
> Rui Fu
> On Jun 6, 2023 at 09:50 +0800, Pengcheng Jiang
> , wrote:
> > Hello, community:
> >
> > This thread is to start a vote for PIP-272: Add stateStorageConfig to
> > WorkerConfig.
> >
> > Discussion thread:
> > https://lists.apache.org/thread/pwfv7nj64frfnbw7jfydzx8my15b3lj6
> > PR: https://github.com/apache/pulsar/pull/20455
> >
> > Sincerely
> > Pengcheng Jiang
>

Re: [DISCUSS] PIP-264: Enhanced OTel-based metric system

[Asaf Mesika]

I'm super happy the video helped convey the long PIP in 30 minutes.


On Tue, Jun 6, 2023 at 8:00 PM Dave Fisher  wrote:

> Hi Asaf,
>
>
>
> Just to be clear to all the phrase you used “we decided” along with the
> timeline is not a Pulsar community we, but a StreamNative corporate we.
> This discussion may, or may not become a Pulsar community we.
>
> When I say "we estimate" and "to provide," it means this is a community
effort. I'm using the guidance of community members to help me do the
estimate and also implement this, pending the community will decision to
proceed and vote on this. I didn't say StreamNative in the video, and it's
unrelated to this discussion at all.

This is a community effort.


> I would find this plan much more reasonable if it were broken down as
> follows.
>
> (1) Implement and prove the use of OTel as an option for metrics as they
> work now. Let this community agree with you from experience.
>
> (2) Have a discussion in the Pulsar community about notions like Topic
> Group and Bundles so that we have the best and most operational logic
> around reducing cardinality and controlling load and performance. As long
> as we have bundles and orthogonally add groups we introduce complexity.
> Topic Groups are useless unless there is some understanding of Bundles and
> Load.
>

The uttermost upper goal of this PIP is to solve the pain of running Pulsar
with hundreds of thousands of topics in a cluster.
The "tool" used to achieve that is Topic Groups and Filtering:
* Groups reduce cardinality since they can be in order or thousands.
* Filtering allows you to filter out all high cardinality topic-level
metrics. Without it, groups are useless in solving the cardinality issue
since you have both topic-level (the culprit) and group-level metrics.
* Filtering is vital also since it allows you to "open" a group to see
detailed metrics for all topics contained within it (like logging level)
but not be flooded with 100 metrics time the number of topics you have. It
enables that by allowing you to choose the specific metric you saw
misbehaving at the group level.

So filtering is vital to the grouping feature.

Also vital is renaming metrics and making order in the naming. You can
filter if you can't "select" a domain using a regular expression (for
example, pulsar_messaging_*, which we can't do today since all messaging
metrics are prefixed with pulsar_ like all other domains
pulsar_transactions). Not to mention some metrics are pulsar_ and some
brk_. It's almost impossible to do filtering without making some proper
ordering to the names.

So in order to solve the huge topics use case pain, you must have both:
grouping, filtering, and proper metric naming.

You can't implement filtering in today's system. You have 4 different
libraries. I can't implement filtering for each one. Not to mention an
impossible interface to work with, we gave to the plugins in the form of
Raw Metrics Provider, which is just bytes out to a stream.

So basically, you have to consolidate all 4 metrics libraries into one to
implement filtering - i.e. switching to OpenTelemetry. All the other
libraries either can't support Filtering at scale or lack vital features we
need in a metrics library. I listed the exact reasons in a special section
in the PIP.

To summarize: Solving large topic count, which is the foremost goal of this
PIP, requires grouping, filtering, and switching to a single library (OTel).

Before I go on this huge road, I need the consent of the community on this
basic idea as a whole.
There is no point in spending a huge effort in switching to OpenTelemetry -
it's a huge effort - without knowing I can proceed to the next steps which
is grouping and filtering.
Having just OTel won't achieve the goal I described.

This is why I'm having this discussion now and didn't break it down into
two PIPs or 10 PIPs. Meaning this is why I created a parent PIP - to give a
coherent high level solution to the goals presented before I proceed.

I'm quoting the PIP from the preface:

> This PIP is a parent PIP. It aims to gradually solve (using sub-PIPs) all
> the current metric system's problems and provide the ability to monitor a
> broker with a large topic count, which is currently lacking. As a parent
> PIP, it will describe each problem and its solution at a high level,
> leaving fine-grained details to the sub-PIPs. The parent PIP ensures all
> solutions align and does not contradict each other.


Of course, this will be done in parts, broken into many sub-PIPs.



You mentioned bundles.
Currently, bundles can't serve as the cardinality reducer unit - they are
not user controlled.

What do you mean by "Topic Groups are useless unless there is some
understanding of Bundles and Load."

Bundles are a key design choice made years ago to load balance Pulsar nodes.
Topic groups are completely unrelated to bundles or load.
Even if you come up with a unique design that introduces an abstraction on
top of topics, it 

Re: [DISCUSS] PIP-264: Enhanced OTel-based metric system

[Matteo Merli]

(2) Have a discussion in the Pulsar community about notions like Topic
Group and Bundles so that we have the best and most operational logic
around reducing cardinality and controlling load and performance. As long
as we have bundles and orthogonally add groups we introduce complexity.
Topic Groups are useless unless there is some understanding of Bundles and
Load.

Isn't this thread the "discussion"? It has been open for more than a month
to let people the time to read and provide feedback on the proposal

--
Matteo Merli



On Tue, Jun 6, 2023 at 10:00 AM Dave Fisher  wrote:

> Hi Asaf,
>
> I just watched your presentation from Pulsar Summit.
> https://www.youtube.com/watch?v=NN4KNK2r4mo <
> https://www.youtube.com/watch?v=NN4KNK2r4mo>
>
> Just to be clear to all the phrase you used “we decided” along with the
> timeline is not a Pulsar community we, but a StreamNative corporate we.
> This discussion may, or may not become a Pulsar community we.
>
> I would find this plan much more reasonable if it were broken down as
> follows.
>
> (1) Implement and prove the use of OTel as an option for metrics as they
> work now. Let this community agree with you from experience.
>
> (2) Have a discussion in the Pulsar community about notions like Topic
> Group and Bundles so that we have the best and most operational logic
> around reducing cardinality and controlling load and performance. As long
> as we have bundles and orthogonally add groups we introduce complexity.
> Topic Groups are useless unless there is some understanding of Bundles and
> Load.
>
> (3) Perhaps the issues of 100s of metrics should be turned to being
> intentional about what metrics are helpful and then slowly switching to
> those that the whole community finds are most helpful in their operations.
>
> Only by doing these three steps carefully in the Open on this list in the
> Community can there be enough consensus that the whole change is acceptable
> for Pulsar 4.0 in 18 months.
>
> Best,
> Dave
>
> > On May 21, 2023, at 9:00 AM, Asaf Mesika  wrote:
> >
> > Thanks for the reply, Enrico.
> > Completely agree.
> > This made me realize my TL;DR wasn't talking about export.
> > I added this to it:
> >
> > ---
> > Pulsar OTel Metrics will support exporting as Prometheus HTTP endpoint
> > (`/metrics` but different port) for backward compatibility and also OLTP,
> > so you can push the metrics to OTel Collector and from there ship it to
> any
> > destination.
> > ---
> >
> > OTel supports two kinds of exporter: Prometheus (HTTP) and OTLP (push).
> > We'll just configure to use them.
> >
> >
> >
> > On Mon, May 15, 2023 at 10:35 AM Enrico Olivelli 
> > wrote:
> >
> >> Asaf,
> >> thanks for contributing in this area.
> >> Metrics are a fundamental feature of Pulsar.
> >>
> >> Currently I find it very awkward to maintain metrics, and also I see
> >> it as a problem to support only Prometheus.
> >>
> >> Regarding your proposal, IIRC in the past someone else proposed to
> >> support other metrics systems and they have been suggested to use a
> >> sidecar approach,
> >> that is to add something next to Pulsar services that served the
> >> metrics in the preferred format/way.
> >> I find that the sidecar approach is too inefficient and I am not
> >> proposing it (but I wanted to add this reference for the benefit of
> >> new people on the list).
> >>
> >> I wonder if it would be possible to keep compatibility with the
> >> current Prometheus based metrics.
> >> Now Pulsar reached a point in which is is widely used by many
> >> companies and also with big clusters,
> >> telling people that they have to rework all the infrastructure related
> >> to metrics because we don't support Prometheus anymore or because we
> >> changed radically the way we publish metrics
> >> It is a step that seems too hard from my point of view.
> >>
> >> Currently I believe that compatibility is more important than
> >> versatility, and if we want to introduce new (and far better) features
> >> we must take it into account.
> >>
> >> So my point is that I generally support the idea of opening the way to
> >> Open Telemetry, but we must have a way to not force all of our users
> >> to throw away their alerting systems, dashboards and know-how in
> >> troubleshooting Pulsar problems in production and dev
> >>
> >> Best regards
> >> Enrico
> >>
> >> Il giorno lun 15 mag 2023 alle ore 02:17 Dave Fisher
> >>  ha scritto:
> >>>
> >>>
> >>>
>  On May 10, 2023, at 1:01 AM, Asaf Mesika 
> >> wrote:
> 
>  On Tue, May 9, 2023 at 11:29 PM Dave Fisher  wrote:
> 
> >
> >
> >>> On May 8, 2023, at 2:49 AM, Asaf Mesika 
> >> wrote:
> >>
> >> Your feedback made me realized I need to add "TL;DR" section, which
> I
> > just
> >> added.
> >>
> >> I'm quoting it here. It gives a brief summary of the proposal, which
> >> requires up to 5 min of read time, helping you get a high level
> >> picture
> >> before you dive into the 

Re: [DISCUSS] PIP-264: Enhanced OTel-based metric system

[Dave Fisher]

Hi Asaf,

I just watched your presentation from Pulsar Summit. 
https://www.youtube.com/watch?v=NN4KNK2r4mo 


Just to be clear to all the phrase you used “we decided” along with the 
timeline is not a Pulsar community we, but a StreamNative corporate we. This 
discussion may, or may not become a Pulsar community we.

I would find this plan much more reasonable if it were broken down as follows.

(1) Implement and prove the use of OTel as an option for metrics as they work 
now. Let this community agree with you from experience.

(2) Have a discussion in the Pulsar community about notions like Topic Group 
and Bundles so that we have the best and most operational logic around reducing 
cardinality and controlling load and performance. As long as we have bundles 
and orthogonally add groups we introduce complexity. Topic Groups are useless 
unless there is some understanding of Bundles and Load.

(3) Perhaps the issues of 100s of metrics should be turned to being intentional 
about what metrics are helpful and then slowly switching to those that the 
whole community finds are most helpful in their operations.

Only by doing these three steps carefully in the Open on this list in the 
Community can there be enough consensus that the whole change is acceptable for 
Pulsar 4.0 in 18 months.

Best,
Dave

> On May 21, 2023, at 9:00 AM, Asaf Mesika  wrote:
> 
> Thanks for the reply, Enrico.
> Completely agree.
> This made me realize my TL;DR wasn't talking about export.
> I added this to it:
> 
> ---
> Pulsar OTel Metrics will support exporting as Prometheus HTTP endpoint
> (`/metrics` but different port) for backward compatibility and also OLTP,
> so you can push the metrics to OTel Collector and from there ship it to any
> destination.
> ---
> 
> OTel supports two kinds of exporter: Prometheus (HTTP) and OTLP (push).
> We'll just configure to use them.
> 
> 
> 
> On Mon, May 15, 2023 at 10:35 AM Enrico Olivelli 
> wrote:
> 
>> Asaf,
>> thanks for contributing in this area.
>> Metrics are a fundamental feature of Pulsar.
>> 
>> Currently I find it very awkward to maintain metrics, and also I see
>> it as a problem to support only Prometheus.
>> 
>> Regarding your proposal, IIRC in the past someone else proposed to
>> support other metrics systems and they have been suggested to use a
>> sidecar approach,
>> that is to add something next to Pulsar services that served the
>> metrics in the preferred format/way.
>> I find that the sidecar approach is too inefficient and I am not
>> proposing it (but I wanted to add this reference for the benefit of
>> new people on the list).
>> 
>> I wonder if it would be possible to keep compatibility with the
>> current Prometheus based metrics.
>> Now Pulsar reached a point in which is is widely used by many
>> companies and also with big clusters,
>> telling people that they have to rework all the infrastructure related
>> to metrics because we don't support Prometheus anymore or because we
>> changed radically the way we publish metrics
>> It is a step that seems too hard from my point of view.
>> 
>> Currently I believe that compatibility is more important than
>> versatility, and if we want to introduce new (and far better) features
>> we must take it into account.
>> 
>> So my point is that I generally support the idea of opening the way to
>> Open Telemetry, but we must have a way to not force all of our users
>> to throw away their alerting systems, dashboards and know-how in
>> troubleshooting Pulsar problems in production and dev
>> 
>> Best regards
>> Enrico
>> 
>> Il giorno lun 15 mag 2023 alle ore 02:17 Dave Fisher
>>  ha scritto:
>>> 
>>> 
>>> 
 On May 10, 2023, at 1:01 AM, Asaf Mesika 
>> wrote:
 
 On Tue, May 9, 2023 at 11:29 PM Dave Fisher  wrote:
 
> 
> 
>>> On May 8, 2023, at 2:49 AM, Asaf Mesika 
>> wrote:
>> 
>> Your feedback made me realized I need to add "TL;DR" section, which I
> just
>> added.
>> 
>> I'm quoting it here. It gives a brief summary of the proposal, which
>> requires up to 5 min of read time, helping you get a high level
>> picture
>> before you dive into the background/motivation/solution.
>> 
>> --
>> TL;DR
>> 
>> Working with Metrics today as a user or a developer is hard and has
>> many
>> severe issues.
>> 
>> From the user perspective:
>> 
>> - One of Pulsar strongest feature is "cheap" topics so you can
>> easily
>> have 10k - 100k topics per broker. Once you do that, you quickly
>> learn
> that
>> the amount of metrics you export via "/metrics" (Prometheus style
> endpoint)
>> becomes really big. The cost to store them becomes too high, queries
>> time-out or even "/metrics" endpoint it self times out.
>> The only option Pulsar gives you today is all-or-nothing filtering
>> and
>> very crude aggregation. You switch metrics from topic 

Re: [DISCUSS] PIP-273: Enable hostname verification by default

[ZhangJian He]

+1. default security is reasonable.

Thanks
ZhangJian He


On Tue, 6 Jun 2023 at 13:40, Michael Marshall  wrote:

> > Should these changes be released in a minor version?
>
> I think it is reasonable to make this change in 3.1.0. The change will
> be covered in the release notes.
>
> > For the Golang client,  I think we should introduce a
> > `NewDefaultConfig` method to create the config instead of directly new
> > config.
>
> Makes sense, thanks.
>
> - Michael
>
> On Sat, Jun 3, 2023 at 9:37 AM Zixuan Liu  wrote:
> >
> > +1
> >
> > Default to enable the TLS hostname verification is important anywhere,
> > which protected our application.
> >
> > Should these changes be released in a minor version?
> >
> > For the Golang client,  I think we should introduce a
> > `NewDefaultConfig` method to create the config instead of directly new
> > config.
> >
> > Thanks,
> > Zixuan
> >
> > Michael Marshall  于2023年6月3日周六 05:39写道：
> > >
> > > I put together PRs for the python and the C++ clients:
> > >
> > > https://github.com/apache/pulsar-client-python/pull/128
> > > https://github.com/apache/pulsar-client-cpp/pull/278
> > >
> > > I am not sure the right way to change the default for the go client
> > > because go uses the zero value for structs, and we have the variable
> > > named "TLSValidateHostname". Would it perhaps make sense to ignore
> > > that variable and instead use "TLSHostnameVerificationDisabled"? Then,
> > > false would be the secure default. However, it introduces a double
> > > negative, which might make it harder for users to understand.
> > >
> > > I plan to start the vote next week.
> > >
> > > Thanks,
> > > Michael
> > >
> > >
> > > On Wed, May 31, 2023 at 11:08 PM Michael Marshall <
> mmarsh...@apache.org> wrote:
> > > >
> > > > Hi Pulsar Community,
> > > >
> > > > I am writing to start the discussion on PIP 273 to enable hostname
> > > > verification by default.
> > > >
> > > > PR with PIP contents: https://github.com/apache/pulsar/pull/20453
> > > >
> > > > I copy the content below (except for the associated svg of the pulsar
> > > > network diagram).
> > > >
> > > > I look forward to your feedback.
> > > >
> > > > Thanks,
> > > > Michael
> > > >
> > > > 
> > > >
> > > > # PIP 273: Enable hostname verification by default
> > > >
> > > > # Background knowledge
> > > >
> > > > When using TLS to secure a network connection from client to server,
> > > > hostname verification is the step where the client verifies that the
> > > > server's certificate contains the expected Subject Alternative Name
> or
> > > > the Common Name. This step is essential for preventing man in the
> > > > middle attacks where a malicious server presents a certificate that
> is
> > > > cryptographically valid but was intended for a different hostname
> than
> > > > the one the client is trying to connect to.
> > > >
> > > > [RFC 2818](https://datatracker.ietf.org/doc/html/rfc2818#section-3.1
> )
> > > > provides additional details on the hostname verification process as a
> > > > part of the TLS handshake and why a client must verify the identity
> of
> > > > the server.
> > > >
> > > > It is very helpful to understand the network topology of a Pulsar
> > > > Cluster when looking to enable hostname verification. Here is a
> > > > diagram I created. It is possibly incomplete:
> > > >
> > > > (see PIP PR to see diagram)
> > > >
> > > > # Motivation
> > > >
> > > > The primary motivation is to improve the security of Pulsar by making
> > > > it secure by default for hostname verification.
> > > >
> > > > Pulsar currently disables hostname verification by default, which led
> > > > to some security issues in the past. For example,
> > > > [CVE-2022-33682](
> https://github.com/apache/pulsar/wiki/CVE-2022-33682)
> > > > happened because there was no way to enable hostname verification
> > > > within the broker or the proxy. If hostname verification had been
> > > > enabled by default, the lack of configurability would not have been a
> > > > security concern but a usability concern.
> > > >
> > > > # Goals
> > > >
> > > > ## In Scope
> > > >
> > > > * Enable hostname verification by default for all clients in the
> > > > Pulsar ecosystem.
> > > > * Make it possible to configure hostname verification per
> > > > geo-replicated cluster.
> > > > * Consolidate the name of the hostname verification configuration
> > > > option across all server components.
> > > >
> > > > ## Out of Scope
> > > >
> > > > * This PIP does not seek to enable TLS by default, which is relevant
> > > > because hostname verification only takes affect when TLS is enabled.
> > > > * Client configuration names will not be renamed because that would
> > > > introduce binary incompatibility.
> > > > * Tiered storage clients
> > > > * ETCd client configuration -- it enables hostname verification by
> > > > default already
> > > > * Zookeeper client configuration -- it enables hostname verification
> > > > by default already
> > > > * Function worker's 

Re: [VOTE] PIP-273: Enable hostname verification by default

[Zixuan Liu]

+1 (non-binding)

Thanks,
Zixuan

Enrico Olivelli  于2023年6月6日周二 16:40写道：
>
> +1 (binding)
>
> Enrico
>
> Il Mar 6 Giu 2023, 10:32 Yunze Xu  ha scritto:
>
> > +1 (binding)
> >
> > Thanks,
> > Yunze
> >
> > On Tue, Jun 6, 2023 at 2:09 PM Michael Marshall 
> > wrote:
> > >
> > > +1 (binding)
> > >
> > > - Michael
> > >
> > > On Tue, Jun 6, 2023 at 1:08 AM Michael Marshall 
> > wrote:
> > > >
> > > > Hello,
> > > >
> > > > This is the vote thread for PIP 273.
> > > >
> > > > PR: https://github.com/apache/pulsar/pull/20453
> > > > Discussion:
> > https://lists.apache.org/thread/7dprl8wvq4r2y8n4p32gwrl6jn97yckq
> > > >
> > > > The vote will be open for at least 48 hours.
> > > >
> > > > Thanks,
> > > > Michael
> >

Re: [VOTE] PIP-273: Enable hostname verification by default

[Enrico Olivelli]

+1 (binding)

Enrico

Il Mar 6 Giu 2023, 10:32 Yunze Xu  ha scritto:

> +1 (binding)
>
> Thanks,
> Yunze
>
> On Tue, Jun 6, 2023 at 2:09 PM Michael Marshall 
> wrote:
> >
> > +1 (binding)
> >
> > - Michael
> >
> > On Tue, Jun 6, 2023 at 1:08 AM Michael Marshall 
> wrote:
> > >
> > > Hello,
> > >
> > > This is the vote thread for PIP 273.
> > >
> > > PR: https://github.com/apache/pulsar/pull/20453
> > > Discussion:
> https://lists.apache.org/thread/7dprl8wvq4r2y8n4p32gwrl6jn97yckq
> > >
> > > The vote will be open for at least 48 hours.
> > >
> > > Thanks,
> > > Michael
>

Re: [VOTE] PIP-273: Enable hostname verification by default

[Yunze Xu]

+1 (binding)

Thanks,
Yunze

On Tue, Jun 6, 2023 at 2:09 PM Michael Marshall  wrote:
>
> +1 (binding)
>
> - Michael
>
> On Tue, Jun 6, 2023 at 1:08 AM Michael Marshall  wrote:
> >
> > Hello,
> >
> > This is the vote thread for PIP 273.
> >
> > PR: https://github.com/apache/pulsar/pull/20453
> > Discussion: https://lists.apache.org/thread/7dprl8wvq4r2y8n4p32gwrl6jn97yckq
> >
> > The vote will be open for at least 48 hours.
> >
> > Thanks,
> > Michael

Re: [DISCUSS] PIP-275: Introduce numWorkerThreadsForPersistentTopic to deprecate numWorkerThreadsForNonPersistentTopic in configuration

[Rajan Dhabalia]

Hi,

We already have a default number of threads for persistent topics but we
have added a feature non-persistent topics and to isolate that path we
introduced a number of worker threads which we can reduce or tune based on
resources we would like to allocate for non-persistent topics. So, it
really doesn't make sense and I don't see any clear reason in this PIP why
we would like to take away control to tune thread resources to
non-persistent topics.

Thanks,
Rajan

On Mon, Jun 5, 2023 at 10:56 PM houxiaoyu  wrote:

> Hi Pulsar Community,
>
> I am writing to start the discussion on PIP-275: Introduce
> numWorkerThreadsForPersistentTopic to deprecate
> numWorkerThreadsForNonPersistentTopic in configuration
>
> PR with PIP contents: https://github.com/apache/pulsar/pull/20507
>
> # Motivation
>
> Introduce `numWorkerThreadsForPersistentTopic` to deprecate
> `numWorkerThreadsForNonPersistentTopic`.
>
> The `numWorkerThreadsForNonPersistentTopic` is used to specify for
> PersistentTopic, not NonPersistentTopic. So I propose change the config
> item from `numWorkerThreadsForNonPersistentTopic` to
> `numWorkerThreadsForPersistentTopic`:
>
> Thanks,
> Xiaoyu Hou
>

Re: [VOTE] PIP-273: Enable hostname verification by default

[Michael Marshall]

+1 (binding)

- Michael

On Tue, Jun 6, 2023 at 1:08 AM Michael Marshall  wrote:
>
> Hello,
>
> This is the vote thread for PIP 273.
>
> PR: https://github.com/apache/pulsar/pull/20453
> Discussion: https://lists.apache.org/thread/7dprl8wvq4r2y8n4p32gwrl6jn97yckq
>
> The vote will be open for at least 48 hours.
>
> Thanks,
> Michael

[VOTE] PIP-273: Enable hostname verification by default

[Michael Marshall]

Hello,

This is the vote thread for PIP 273.

PR: https://github.com/apache/pulsar/pull/20453
Discussion: https://lists.apache.org/thread/7dprl8wvq4r2y8n4p32gwrl6jn97yckq

The vote will be open for at least 48 hours.

Thanks,
Michael