Please find the response inline.
On Wed, Jun 21, 2023 at 5:53 PM PengHui Li wrote:
> > However, stats retrieval over HTTP API doesn’t work well in use cases
> when users would like to access this API at a higher scale when a large
> number of application nodes would like to use it over HTTP whic
> However, stats retrieval over HTTP API doesn’t work well in use cases
when users would like to access this API at a higher scale when a large
number of application nodes would like to use it over HTTP which could
overload brokers and sometimes makes broker irresponsive and impact admin
API perfor
Hi Rajan,
I think we discuss the newly added field in the
PulsarApi.proto at
https://github.com/apache/pulsar/pull/19944#discussion_r1153963425
But the proposal doesn't mention it.
Although I know why we need to add that field to the proto file
to avoid introducing many changes to the client side
+1 (binding)
Though I agree with Asaf that this proposal itself is not clear, I think the
design
Is easy to understand from the PR that a new field is added only for
serialization
and deserialization for a MessageId.
Thanks,
Yunze
> On Jun 21, 2023, at 03:08, Asaf Mesika wrote:
>
> -1 (non-b
Looking into the discussion and reviewing our membership list, from module
experts' distribution perspective, I agree that specific modules can have
fewer PMC members overseeing.
According to my experience in the Flink community[1] and the natural that
improvement proposals are mainly about develo
On 2023/06/21 07:21:31 Asaf Mesika wrote:
> Lari, would it be possible to explain in more detail the paint points
> you're describing?
Well the point of the pluggable Function runtime types is to support other
technologies. Let's forget the reactive messaging solution for a moment.
With a plugga
On 2023/06/20 09:12:28 Enrico Olivelli wrote:
> > I am interested to know your thoughts on making the Pulsar Functions
> > runtime pluggable so that we can add new runtime types.
>
> I see that RuntimeFactory [1] is already customizable.
> What can we do more ?
> Are you talking about providing al
> mostly part of one enterprise and only their PIP/PRs are moving forward
No. PIPs are processed in a vendor natural bias. At least the difference
between lazy consensus and at least 3 +1 binding votes won't change it.
> help other community members to let them contribute to Pulsar so
I'm doing
On Wed, Jun 21, 2023 at 10:27 AM Zixuan Liu wrote:
> I think we can reference https://www.apache.org/foundation/voting.html
>
> > Votes on code modifications follow a different model. In this scenario,
> a negative vote constitutes a veto , which the voting group (generally the
> PMC of a project
I think we can reference https://www.apache.org/foundation/voting.html
> Votes on code modifications follow a different model. In this scenario, a
> negative vote constitutes a veto , which the voting group (generally the PMC
> of a project) cannot override. Again, this model may be modified by
Lari, would it be possible to explain in more detail the paint points
you're describing?
You say processing messages individually is slow; hence, processing them in
batches is better. I guess it's especially useful if you need to group a
batch based on a key. What I don't understand is how the fra
Hello Devin,
The support for the avro scheme in Python function is just added and
released in v3.0.0
There is an example of using avro in Python function:
https://github.com/apache/pulsar/blob/660525e57ed35b74cb9204521d1fba02cc08c542/pulsar-functions/python-examples/avro_schema_test_function.py
I'll continue this on Slack #dev and write the summary here.
Just to clarify any misunderstanding: My intention is to make Pulsar PIP
readable by anyone, which means: Adding the required background information
and explaining your idea in a way people can understand.
In light of this goal, I've in
13 matches
Mail list logo
